Core Web Vitals Explained
Panelists discuss the Remix docs controversy, Core Web Vitals vs. Lighthouse, Google's delay in phasing out 3rd-party cookies, and full-stack frameworks
Episode Description
JavaScript Jam Live covers the Remix vs SolidJS docs drama, explains Core Web Vitals vs Lighthouse, and debates whether JS can match Rails-like frameworks.
Episode Summary
This episode of JavaScript Jam Live, hosted by Matt filling in for Scott, opens with a heated discussion about a controversy between the Remix and SolidJS communities after documentation from Remix appeared to be copied into unreleased Solid Start docs. Anthony Campolo argues that Ryan Florence's public Twitter reaction was disproportionate and harmful, while others offer more sympathetic views, noting a pattern of open source maintainers feeling underappreciated. The conversation shifts to a technical breakdown of Core Web Vitals versus Lighthouse, where Matt explains that Lighthouse is a synthetic lab tool while Core Web Vitals reflect real user data collected by Chrome — and critically, only Core Web Vitals influence Google search rankings. He outlines a practical framework: start with Core Web Vitals as your ground truth, calibrate Lighthouse results against them, run experiments in Lighthouse's fast lab environment, then validate changes with real user monitoring. The episode also touches on Google's delayed third-party cookie phase-out and its implications for advertising and shared logins. The final segment explores whether the JavaScript ecosystem can ever achieve a Rails-like developer experience, with speakers comparing Remix, Next, Blitz, and Redwood, and debating whether JavaScript's culture of avoiding opinionated frameworks fundamentally prevents it from reaching that goal.
Chapters
00:00:00 - Introduction and the Remix vs SolidJS Documentation Drama
Matt opens the show as a substitute host, welcoming the audience to JavaScript Jam Live and encouraging participation. Anthony Campolo quickly steers the conversation toward the day's biggest controversy: documentation from the Remix framework was found copy-pasted into unreleased Solid Start docs, and Ryan Florence responded with an angry public tweet rather than handling it privately.
Anthony argues that the copied content came from an obscure contributor, wasn't part of any publicly released documentation, and could have been resolved quietly. He criticizes what he sees as a recurring pattern where Ryan reacts emotionally on Twitter, damages other projects' reputations, and then deletes his tweets. Matt pushes back gently, acknowledging he can see both sides, while Daniel suggests Ryan should be flattered that Remix is significant enough to be copied.
00:05:15 - Weighing Both Sides of the Open Source Dispute
The panel digs deeper into the consequences of public callouts in the open source community. Anthony explains that the real damage is reputational — developers hearing about SolidJS for the first time may walk away thinking the project is untrustworthy based on a single tweet they saw before the full context emerged. Matt notes that the Remix team may feel a broader pattern of their innovations being adopted without credit, pointing to a similar incident when Next.js proposed nested routes.
Ishan Anand frames the discussion around what temperament is expected of major open source maintainers, suggesting that how you react publicly carries weight proportional to your platform size. The group agrees that while emotions are valid, the downstream effects of public blowups are worse than private resolution would be, and that building trust through private communication leads to a healthier collaborative ecosystem.
00:17:39 - Core Web Vitals vs Lighthouse: Understanding Web Performance
Matt transitions to a technical topic sparked by a recent Twitter conversation and a Smashing Magazine article about web performance tools. He explains that Lighthouse is a synthetic lab measurement that simulates page loads and scores them against benchmarks, while Core Web Vitals represent real user behavior data collected by Chrome browsers across millions of users. He walks through key metrics including Largest Contentful Paint, Time to Interactive, First Contentful Paint, and Cumulative Layout Shift.
The critical distinction, Matt emphasizes, is that Google uses only Core Web Vitals — not Lighthouse scores — to influence search rankings. He illustrates this with a case study comparing COVID vaccine websites across all 50 U.S. states, where Lighthouse scores and actual user experience metrics showed only loose correlation. A site scoring 30 on Lighthouse could have the same real-world LCP as one scoring 80, depending on user demographics and device characteristics.
00:28:02 - A Practical Framework for Performance Optimization
Anthony asks how developers can build a culture of testing across different performance tools. Matt outlines a practical workflow: begin by checking Core Web Vitals to understand your real-world standing, then calibrate your Lighthouse results against those numbers. Use Lighthouse as a rapid experimentation tool — running hundreds of simulated changes to see what might improve metrics — then validate those changes against real user data through RUM tools or Google's Chrome User Experience Report.
He explains that Google's CRUX data updates on a 28-day rolling average, making it too slow for iterative development, which is where third-party RUM tools and Lighthouse fill complementary roles. Anthony also highlights the newer Lighthouse user flow recorder feature, which addresses a longstanding limitation where Lighthouse could only measure first page loads and unfairly penalized fast single-page applications during subsequent navigation.
00:35:27 - Third-Party Cookie Phase-Out and Advertising Implications
After a brief station break, Matt raises Google's postponement of their third-party cookie phase-out. Anthony takes a firm stance that cross-site tracking should require explicit opt-in consent. Matt acknowledges the privacy arguments but raises counterpoints: third-party cookies support shared login experiences and targeted advertising that funds much of the free web, arguing that the reality is more nuanced than a simple privacy-versus-tracking binary.
The group briefly discusses the now-abandoned FLoC proposal and its replacement Fledge, noting that third-party advertising providers have objected to these alternatives as favoring existing incumbents. The conversation is briefly interrupted when Theo appears in the Twitter Space but leaves before contributing, prompting laughs about what his take on the Remix drama might have been.
00:41:14 - Remix, Next.js, and the Serverless Architecture Discussion
A community member joins the stage to share observations about how Remix handles serverless deployment differently from Next.js. He argues that Remix creates what feels like a serverful environment out of serverless routes, treating every route dynamically rather than separating API routes from page routes. Daniel agrees, noting that Remix feels more complete out of the box while Next.js follows React's philosophy of building your own solution layer by layer.
Matt connects this to Remix's origins in classic server architecture with a CDN-server-database model, contrasting it with Next's incorporation of Jamstack patterns. The discussion highlights how Remix's modular adapter system allows deployment across diverse platforms like Vercel, Netlify, and Architect, giving developers flexibility that feels natural to those who previously coupled Express with React manually.
00:48:31 - Can JavaScript Ever Match the Rails Experience?
The final segment explores whether JavaScript frameworks like Blitz and Redwood can deliver on the promise of a Rails-like developer experience. Anthony cautions that Blitz is mid-transition and essentially impossible to evaluate right now, as its direction has shifted between being a backend toolkit and remaining a full-stack framework. Daniel shares his perspective as someone who has used Rails, Laravel, and the JavaScript ecosystem extensively, arguing that no JS framework has matched the plug-and-play productivity of Rails.
Daniel attributes this gap to cultural differences: the JavaScript community historically resisted opinionated frameworks, preferring to control every layer, whereas Rails culture prioritized shipping fast and worrying about scale later. The episode closes with brief discussion of Kong's migration from JVM to JavaScript for scalability reasons and speculation about how serverless has transformed JavaScript's viability as a backend language, with Matt signing off and handing future hosting duties back to Scott.
Transcript
00:00:00 - Matt (filling in for Scott)
Hello everyone. Getting the room set up. Thanks for joining. Our normal host, Scott, is out of the office today, so my name is Matt and I will be the host. I'm getting all our speakers. Ishan is here, Daniel is here. Michael, I saw that you raised your hand. I approved it. I don't know if you changed your mind, but feel free to come up on stage. We love community contributions. While you're doing that, I will just kick us off and fill in for Scott. Welcome to JavaScript Jam Live. JavaScript Jam is a podcast for front-end and full-stack developers. JavaScript Jam Live is our every-week, Wednesday-at-12 p.m., San Francisco-time-zone open mic for anything JavaScript- and web-development-related. We always come with some topics to
00:01:00 - Anthony Campolo
discuss, which we'll have no topics today, I'm sure.
00:01:04 - Matt (filling in for Scott)
Well, I couldn't tell if you were being sarcastic or not, but we love to be as audience-driven as possible. Look, when we're talking on something, feel free to raise your hand. This is a Twitter Space, so it's very audience-driven. Raise your hand, we'll bring you up to the stage. You can introduce the topic or you can comment. Add your voice to what we're talking about. Our favorite episodes are actually the ones where somebody in the audience asks a question and somebody in the audience answers it. And lastly, whether you're a beginner or an expert, we want to hear from you. Don't be intimidated. We'll go from the most sophisticated topics to, I think every other episode, somebody asking about how to break into the industry. So with that said, Anthony, were you being sarcastic or were you...
00:01:54 - Anthony Campolo
Well, do you know whether there is something happening today? Have you seen this?
00:01:58 - Matt (filling in for Scott)
No, I haven't. I've been so heads down in work.
00:02:02 - Anthony Campolo
Okay, that makes sense. You just have to look into it. If you had, I'm pretty sure you're following enough people to see this.
00:02:09 - Matt (filling in for Scott)
Oh, okay. So let me pull it up.
00:02:12 - Anthony Campolo
Okay, so I'll break it down for people in the audience. I've been following this for like three hours. So there's some hot drama happening between, guess who, Remix and another framework. Ryan has a very bad habit of getting very angry at things and then immediately going on Twitter, writing an incredibly angry tweet about it, blasting it out to the world, and then walking away for three hours, letting everyone figure out what actually happened. Then he comes back and deletes the tweet and pretends like the whole thing didn't happen. He's done this at least three times. I've seen him do this. And so basically, someone in the Solid docs copy-pasted some stuff from the Remix docs, and they're like, they're stealing stuff from Remix. And it's not really clear how it got into the docs because Dan, who's in charge of the docs, was accused of a bunch of stuff. He said, "I didn't do this. This is a contribution from someone else by accident. If we knew this, we would have fixed it." So it was a small, minor thing that Ryan could have just sent a message about to them to work it out and say, "Hey, this is not cool. Either credit us or take this out."
00:03:22 - Anthony Campolo
They would have been like, "Yeah, you're right, we'll credit you or take this out." But instead, he just goes online swinging his thing around and just being a douche. So I don't know. I have no patience for Ryan anymore. I think this is ridiculous. I think it makes him look really bad. I think Dan is being attacked for no reason. I don't know. It makes me really, really mad.
00:03:44 - Matt (filling in for Scott)
Tell us how you really feel. So I'm catching up to this, and I saw the now-screenshotted tweet, basically. And let's be clear: a piece of documentation from the Remix framework was, it looks like, literally copy-pasted into the documentation of SolidJS.
00:04:10 - Anthony Campolo
Yes. If that did happen, that is correct. Like, it's obvious. You can put the two next to each other. It's the same doc. So yes, they are correct. They're not making that part up.
00:04:19 - Matt (filling in for Scott)
Okay, so it should be very clear. I assume that SolidJS documentation is tracked in GitHub, so it should be really clear how this happened. Anyone should be able to understand in a matter of minutes.
00:04:38 - Anthony Campolo
Right? And I went back and it was someone who I have no idea who they are. They don't seem to have a lot of presence in this Solid community. English might not even be their first language. So it's like there are so many people involved with this stuff, and there are things that happened that didn't go through the right lines of communication. And I think they've referenced other pieces from the Remix docs before, but they did credit it. So it may be that they meant to credit it, but they didn't. So hard to say.
00:05:03 - Matt (filling in for Scott)
And by the way, I saw the Will Smith slap meme on this that you tweeted out, if people want to go to Anthony's Twitter.
00:05:15 - Anthony Campolo
Yeah, if you go to my Twitter and watch, the last five or six tweets I've sent out have been related to this, if you want to see more.
00:05:21 - Matt (filling in for Scott)
Yeah, I'll say a very apropos use of the meme. But my gut reaction, and I know they aren't known for necessarily being the most diplomatic, but I could understand at first blush why Ryan might be upset. And I don't see why it's so off base. Can you explain to me for him to just be like, "Hey, this looks like a literal copy and paste"? And yeah, he could maybe spend a few minutes to go through it, but he can see it doesn't look good. Like, yeah, I agree, more diplomatic to go...
00:05:58 - Anthony Campolo
It's about how you respond to it. It's about how you choose your own actions. You get to decide what you do with that, you know? So he can decide to ask questions and figure out what happened, or he can decide to go throw a hissy fit on Twitter without actually figuring out what happened. That's up to him.
00:06:16 - Matt (filling in for Scott)
Is putting a screenshot and capturing it for posterity a hissy fit?
00:06:23 - Anthony Campolo
No, that's what I did to him. I'm saying the fact that he claimed that these people are doing something bad for XYZ reason. But okay, so first off, these aren't the Solid docs. These aren't the Solid Start docs. There are no Solid Start docs. The Solid Start docs are a completely separate repo that's being worked on by Dan that I've looked at. Yeah, these are not even the Solid Start docs. Solid Start is not even released.
00:06:50 - Matt (filling in for Scott)
So wait, you're saying Solid Start is in development. It's not their publicly facing docs.
00:07:01 - Anthony Campolo
Yes.
00:07:02 - Matt (filling in for Scott)
Ah, okay, so I misunderstood. So nobody saw this, really?
00:07:07 - Anthony Campolo
It's as if, unless you're diving into these repos and finding these commits, someone found the commit, added Ryan on GitHub, and then he saw that and went and flipped out about it. But this is not. If you go to the actual solidjs.com, you won't see this.
00:07:25 - Daniel
Right. It's kind of like the Next spin-up for Solid. I've used it before. I mean, if anything, I feel like Ryan should be flattered. At least they're big enough to be copied, you know? That's one perspective.
00:07:44 - Matt (filling in for Scott)
You know, I'm looking at the tweet he sent, and I think he's... So now I have a better understanding of, Anthony, why you feel like he had to go looking for this. It was never publicly released. It's kind of like seeing the sausage being made. But to be completely candid, I kind of can see the other side of it, like without...
00:08:10 - Anthony Campolo
But you know, the other side. You wouldn't know the other side if I didn't tell it to you because Ryan wouldn't have given you the other side.
00:08:15 - Matt (filling in for Scott)
That's true. That's true. And he could have gone more diplomatically and actually gone through the commit history. But, you know, what I...
00:08:31 - Daniel
I want to say, like, isn't Remix open source? I saw Tim's tweet about it. I was curious.
00:08:38 - Matt (filling in for Scott)
It is open source.
00:08:40 - Daniel
Yeah.
00:08:42 - Matt (filling in for Scott)
So the license lets you do this. That's not, I think, what he's... I think it just feels weird if you work on something and it's your heart and soul and it's your baby, and somebody takes pieces of it and you're like, that is literally pieces of it there. And I feel like they probably feel, I don't know what the right word is, but they were doing nested routes as a feature and sure enough, that's now being copied. It was an innovative move. But look, it's an ecosystem. Everyone learns from each other. But it's not like they copied the code. It's not like they copied the literal text. And in the grand scheme of things, this is not going to sink or swim them. So they could have gone about it a different way. But I think he reacted from an emotional place.
00:09:45 - Anthony Campolo
And I know, I think that's totally... people are valid to have their emotions, but I think if you're someone with as large of a platform who's putting messages out into the world that are related to other people doing things that are right or wrong, you also have a responsibility to do that in a way where you're not putting someone on blast without all the information being made available. That's my issue.
00:10:07 - Matt (filling in for Scott)
So your problem is that he blasted...
00:10:10 - Anthony Campolo
out to everyone in a way where it clearly only told one side of the story.
00:10:17 - Matt (filling in for Scott)
Got it.
00:10:19 - Anthony Campolo
And I think it shouldn't have been a public thing at all. That's why I think he should have talked to them, he should have messaged them, and he should have said, "Hey, this isn't cool," and they would have agreed with him, and they would have said, "Yes, we need to fix this," so the whole thing could have been worked out. The whole thing didn't need to blow up like this. It was because of the way he decided to react to it that it had to blow up this way.
00:10:38 - Matt (filling in for Scott)
Okay. I mean, in the grand scheme of Twitter reactions, maybe he just wanted to capture for posterity that this happens. So if there's a...
00:10:52 - Anthony Campolo
He wouldn't have deleted it if he cared about capture for posterity.
00:10:55 - Matt (filling in for Scott)
Well, that's true.
00:10:56 - Anthony Campolo
Maybe later.
00:10:57 - Matt (filling in for Scott)
Yeah, look, I guess I haven't been following every single tweet. So let me understand. What do you think is the consequence of him blasting it out publicly like this?
00:11:11 - Anthony Campolo
People who were interested in Solid and who have been hearing, "Solid's cool and up-and-coming," go, "Oh, those Solid douches are just a bunch of plagiarists and I should never even use Solid."
00:11:20 - Matt (filling in for Scott)
Got it. Okay.
00:11:23 - Anthony Campolo
So that's a take a lot of people had, looking at that one tweet and then walking away for the rest of the day.
00:11:28 - Matt (filling in for Scott)
And yeah, this is only even the documentation. It's not even how they work. It's not like you and I would know. That doesn't make any sense because they're fundamentally different. Well, not fundamentally... they're both very, very different. That wouldn't make sense. And this is just about the documentation, but I totally understand what you're saying here. So was there a similar thing that...
00:11:50 - Ishan Anand
happened with nested when Next sent out their proposal for nested routes?
00:11:57 - Anthony Campolo
Pretty much identical. Yeah. He tweeted about it and freaked out about it. And then the Next team was like, "Yeah, okay, we'll give you credit, sure." And then a bunch of people were like, "Hey, guess what, SvelteKit did this actually before both of you. Suck it." So.
00:12:11 - Matt (filling in for Scott)
So yeah, that gets me to the point where... and that was a great question to ask because that is my extrapolation, that they must feel underappreciated or underacknowledged for their contributions or their innovations. So for them, from their side, it looks like, I don't know, a pattern. So I have to say I'm kind of empathetic to both sides to a certain extent. The other part that I mean, we got to remember, I'm trying to put myself in their shoes, which is they built Remix for a long time before it was open source. And they were toiling away and they probably didn't get enough recognition for what Remix was doing. And then they finally open-sourced it, and as they started picking up steam, they now feel like they're maybe being copied by other folks in the ecosystem, which is part of the natural process of the ecosystem.
00:13:16 - Anthony Campolo
And they haven't gotten any recognition? I just don't hear that. I think they were the most talked-about framework of all of 2021. Everyone's talking about Remix. They're incredibly hyped. They're changing the game. They got plenty of credit.
00:13:29 - Matt (filling in for Scott)
Okay, so you're right. My statement was inaccurate. If there's any... you're absolutely right. They've been highly recognized. But they might feel like they haven't gotten maybe the amount they deserved. But I'm not gonna sit here and put myself in their head too much.
00:13:45 - Anthony Campolo
Like I said, this is partly based on a pattern of behavior of Ryan that I'm looking at. It's not just this one specific individual situation, in all of these situations. There's a lot of nuance. Some people are in the right and some people are in the wrong. But it's like every single time, when this happens and you go blow it up on Twitter, it has worse downstream effects than if you just reach out to people and try and work it out in private. And then you'll build trust and you'll build better relationships and you'll build a healthier, more collaborative open source ecosystem. That is what is important to me.
00:14:18 - Matt (filling in for Scott)
Yeah. So what do you think? Yeah, go ahead. No, I was just going to say...
00:14:23 - Ishan Anand
I guess that's just a question of what temperament is required for major open source maintainers. The diplomatic way to look at it, from that perspective, is: as a major voice in the ecosystem, how should you react when bad things happen? Not that I'm going to police how people react, but that's probably the way to look at this. And as someone who's been part of a couple of significant frameworks over the years, seeing something get copied or inspired by is definitely frustrating, especially if you're not the main player on the stage anymore. But anyway, I can understand it. But how you react publicly and the approach that you take, there's a maturity level there that maybe would help elevate the dialogue or the discourse in the open source community.
00:15:25 - Matt (filling in for Scott)
So, you know, I don't spend too much time on... what is... I don't know, psychology.
00:15:31 - Anthony Campolo
Yeah. I got nothing else to say on that.
00:15:33 - Matt (filling in for Scott)
Yeah. But what do you think the consequences of this are for the popularity of both frameworks, or is this probably gonna be minimal?
00:15:46 - Anthony Campolo
It's hard to say because you may bring more attention to Solid. It's like that all-news-is-good-news kind of thing, you know? So yeah, I think it's hard to say what the consequence will be. I mean, most of this stuff ends up being a wash after like a week.
00:16:00 - Matt (filling in for Scott)
Yeah. And well, I learned on this call...
00:16:04 - Ishan Anand
that Solid is doing a Next-like thing. So I hadn't known that before now. So maybe there's that all-publicity-is-good-publicity angle.
00:16:18 - Matt (filling in for Scott)
Yeah, maybe.
00:16:20 - Anthony Campolo
Yeah. I think the consequences more have to do with the ongoing relationship between the different teams and how the kind of alliances are drawn and things like that. Because a lot of people will see stuff like this and they won't know there's kind of a much, much, much larger narrative actually going on here that's across many, many years. So yeah, it's just another link in the ever-epic story of open source frameworks.
00:16:47 - Matt (filling in for Scott)
That's actually the part that I'm probably... I'm not as in it as you are to connect that narrative together. And it's something Theo, in previous episodes, has kind of alluded to, that the relationships between some frameworks and React are different. Clearly this was not, I think, intentional, it looks like. Well, not clearly, but that's my assumption. But I think we've covered this one. Unless anybody else has any other thoughts on this...
00:17:27 - Anthony Campolo
By the way, Ramon or Mike, if you guys want to hop up and join the conversation, please do. What else we got going on this week, Ishan?
00:17:39 - Matt (filling in for Scott)
Okay. Well, let me go to our notes doc. The other thing that came up over the past week, and actually, Anthony, you were part of this one, was a conversation about Core Web Vitals and Lighthouse. Oh, sweet.
00:17:57 - Anthony Campolo
Yeah. I mean, that was like the conversation I pre-blasted out.
00:18:01 - Matt (filling in for Scott)
Yeah. And then this week, I think, was it yesterday? There was a Smashing Magazine article. Let me double check. Yeah, there's a Smashing Magazine article. It was from yesterday called "Core Web Vitals Tools to Boost Your Web Performance Scores." But the tweet that you and I were on, I think a few days ago, was somebody using Lighthouse to measure performance. And we used to talk a lot about this, and I come from a performance background, so I kind of overcompensated and didn't talk about this. But I thought it'd be a useful thing to revisit: Lighthouse, Core Web Vitals, and how you measure a performant website, because it's something that comes up every once in a while and it seems like there's a lot of confusion. So I guess I'll start at the beginning. Core Web Vitals and Lighthouse are those terms, first of all, that people feel like they're very familiar with.
00:19:02 - Anthony Campolo
People here will definitely know Lighthouse. I think it would be useful to explain: what is Lighthouse doing to build on top of Core Web Vitals? Core Web Vitals is like the underlying metrics we use, and then Lighthouse is like a tool that lets you kind of discover those metrics. That's how I would describe it.
00:19:22 - Matt (filling in for Scott)
Maybe I'm too close to the weeds. I would say the biggest difference between Core Web Vitals and Lighthouse is Lighthouse is a synthetic lab measurement. It is a measurement of those measurements.
00:19:40 - Anthony Campolo
Are Core Web Vitals measurements?
00:19:42 - Matt (filling in for Scott)
Well, not always. There's a subset, so there's a...
00:19:47 - Anthony Campolo
And the numbers are like, the performance numbers are...
00:19:53 - Matt (filling in for Scott)
So Lighthouse will track... Let's start with Lighthouse. Let's not put labels to things and just describe what they do. Lighthouse runs your web page. It used to be the first load, but now you can actually record user flows and interactions, which is a great improvement. And it will keep track of a number of different metrics as you do that. So it'll look at a metric called Largest Contentful Paint: how long does it take for the largest image above the fold to render? And then another one it will look at is a metric called Time to Interactive, which is a measure of how long it takes, basically the simplest way to say it, for the JavaScript on the page to be done executing at first load so that it's now ready for the user to respond. There's another one, First Contentful Paint: how long does it take for any piece of content to be drawn? The page doesn't have to be an image. It's got a collection of metrics, and it then measures how long those take, which is usually... it simulates on your desktop, it slows the loading of the browser down.
00:21:12 - Matt (filling in for Scott)
Actually, it no longer does that. It actually lets it run at normal speed and then extrapolates what the slower version would be, depending on which Lighthouse setting you use. And then it compares that against some benchmark. So let's say your LCP is 1.5 seconds. It'll then look at what LCP is for the broad set of websites on the web, and let's say the median value is some number of seconds. It'll then compare that and give you a numerical score from 1 to 100 relative to how your LCP matches the rest of the distribution of LCPs on the web. And then it weights each of those into a calculation that gives you a score from 1 to 100, what your Lighthouse score is. So that was a really complex explanation, but the key thing is that it takes a bunch of measurements of your web page by simulating how the page loads. Okay, so Core Web Vitals can be used to refer to two things. There is a subset of those metrics that Lighthouse also tracks that are used by the Chrome browser to measure real user behavior when they're actually on your website.
00:22:36 - Matt (filling in for Scott)
So there's millions of people, maybe billions, using the Chrome browser. And as they're interacting with your website, Google and Chrome are keeping track of performance data. They're not necessarily tracking users, but they're tracking how long that domain takes and that URL takes to load the largest image or how long it takes that JavaScript to execute. The key difference here is this is the behavior of real users and not a simulation on your page. And they look at a subset of the metrics that Lighthouse looks at. With me so far, or should I pause here for questions?
00:23:19 - Anthony Campolo
Yeah, that was good.
00:23:21 - Matt (filling in for Scott)
Okay, so the key thing to know is that when Google ranks your site by page speed... We all know that page speed means a faster website should get you faster conversions. But what Google started doing is saying that a faster website will now mean you get a higher rank in organic search results than a competitor who may be slower. So that means people who haven't even visited your site, or would not have visited your site to begin with, if you improve your performance, will now get there. That's the type of thing you would throw ad budget at, like, let me spend money to bring people to my site. Now improving your speed brings new people to your site. That's a huge change. It's very significant for a lot of businesses because for many of them, organic search traffic can be 50% or more of your traffic. And so Google looks at Core Web Vitals and they don't look at Lighthouse, which means they look at how real user behavior is on your website. And Core Web Vitals is three metrics: Largest Contentful Paint, another metric called First Input Delay, which measures how long the JavaScript takes on first load...
00:24:37 - Matt (filling in for Scott)
Then another one called Cumulative Layout Shift, which is actually not a performance metric, it's a user experience metric. It measures how much things jump around on a web page during browsing and loading, basically how long it takes for elements to settle on the page when you load a web page. Those three metrics, and only those three metrics, are used to measure and rank your site in search results. And they only come from real users. So the key thing here is it is possible to get a low Lighthouse score, like in the 30s, and still be passing Core Web Vitals. It's, I suppose, possible for the opposite to be true, although I've seen that less commonly. So the very first thing you want to do when you evaluate your website is look at it in terms of how Google ranks its performance, if that's your goal, which is an ROI for performance. Look at what the Core Web Vital scores are, because you may be passing, and Lighthouse might tell you to go fix the wrong things that don't matter to your Core Web Vitals score.
00:25:53 - Matt (filling in for Scott)
An example of this is, if you remember when the first COVID vaccines rolled out, every state in the U.S. had its Department of Health in charge of rolling out the vaccines. And one of the online journals did a comparison of all 50 COVID vaccine websites across every state and looked at their accessibility and their performance all through Lighthouse. And the issue was that Lighthouse was entirely synthetic. If you looked at the Core Web Vitals score, which is actual user behavior and user impact, you would see that there were some sites where one had a 30 and one had an 80, but the Largest Contentful Paint was the same for both of them for actual users. The question is, how does that happen? Well, I'll give you some examples of how that could happen. If your users happen to be using a faster internet connection, or your users happen to be from a demographic that has a more powerful phone, your Core Web Vital score is going to be better than the same identical site with a different audience. And Lighthouse measures a very, very stringent bar, which used to be like a 3G mobile phone and a version of Android, really tailored to, I would say, more an international context than a reflection of, say, the U.S. domestic context.
00:27:29 - Matt (filling in for Scott)
And so it can grade things a lot harsher than what actually happens in real life. And I tweeted this out at the time. There's a talk I gave, I think it was a year ago at React Day New York, that walked through this example, and you can see across the 50 sites how they compare in Lighthouse, which is what the journal published, and here what Core Web Vitals said. You could see that they weren't always correlated. They're related very loosely, but there's not a very strong correlation. So how do you think that...
00:28:02 - Anthony Campolo
do you think we can build a culture of testing across different tools like that? I think this kind of gets at why I think this can be an issue because every measurement is useful to a point, but in isolation they can always be misleading.
00:28:21 - Matt (filling in for Scott)
So this is actually in that talk. I think it was React Day New York. Let me see if I can find it.
00:28:29 - Anthony Campolo
React.
00:28:29 - Matt (filling in for Scott)
I think I replied to your tweet with it. But basically what you need to do is you need a framework for how you think about it, and you deploy the right tool at the right time. So the simplest framework I proposed was to say: start with your Core Web Vitals to see where you truly stand, then calibrate the results you get at Lighthouse to your results in Core Web Vitals. And if your Lighthouse goes up or down, you know it'll affect that core vital, but you also know not to take that number literally. Lighthouse might say your LCP is extremely bad and it got worse, and you know it got worse, but it may not fail by that number. Don't take that number literally. Correlate it to what your Core Web Vitals was for the old number, and that's probably the best way to reconcile it. Different tools have different places, and again, that is in that framework. And the reason why you correlate them is because it is based on real user behavior. Your Core Web Vital score is published by Google on a rolling average across 28 days. So what this means is, you roll out a change to optimize your website...
00:29:41 - Matt (filling in for Scott)
You don't know if it's actually going to improve your Core Web Vitals. It's like an A/B test. You have to wait potentially 20, 28 days, or you have to wait for that traffic to come in. If you use a third-party RUM tool, which Edgio has and a bunch of other folks have, our RUM tool will tell you your results in minutes. But you still want to get some amount of valid data. So wait a few days to know whether that optimization you rolled out actually improved your performance for real users. You don't really know to have done that A/B test, but if you have to wait a few days, or that long, for every single change, it becomes really hard to take a website and optimize it. That's where Lighthouse is really useful, because with Lighthouse you can run a thousand simulations. You can be like, well, what happens if I take this library out? Okay, what happens if I delay the loading of this? What happens if I move this below the fold? How is that going to impact my LCP, one of my Core Web Vitals, or my Lighthouse score?
00:30:44 - Matt (filling in for Scott)
You can run a thousand different experiments in the lab, so to speak, on your device to see what's likely to actually improve your users' Core Web Vitals scores. You start with Core Web Vitals, look at how it correlates to Lighthouse, then sit with your laptop for a few days and try a bunch of experiments against Lighthouse, knowing how it correlates to your Core Web Vitals, and then roll out your result live to your users, ideally in an A/B test, so you can know whether it actually improved your Core Web Vitals or not. So you need to use the right tool at the right spot, so to speak. Does that kind of address the question you're raising? It's a good question.
00:31:27 - Anthony Campolo
And you've always told me about this, but you know other ways to do this. You want to actually do RUM, real user monitoring, right? You don't want to do synthetic stuff.
00:31:37 - Matt (filling in for Scott)
Yep. Yeah. So Lighthouse is synthetic. I'm using Core Web Vitals as... if you get the data from Google, it is called the Chrome User Experience Report, or CrUX. And it is kind of a RUM of last resort. Google's collecting the data, but they don't give it to you every day. They give it to you on this rolling 28-day basis. And it's not broken out necessarily the way you want to think of your site. So it might be just for your domain. You can get it by page, and only in limited time forms. If you want to know if you've got a performance issue, it may just be affecting your product pages, but not your homepage or your category page, if you're, say, an e-commerce site. You want a tool that lets you triangulate where the problem really lies, in addition to being able to roll an experiment out and then know the next day whether you've improved. Google's tools don't let you drill down the way you want. They try to, but they don't really give you that data, and they've got that long 28-day latency. So I would say you kind of need to know both.
00:32:52 - Matt (filling in for Scott)
But I would look at RUM as the ground truth and the validation step. And I would look at Lighthouse and synthetic testing as what you do your experiments on, in terms of coming up with ideas. And then when you roll them out, you have to go back to that ground truth of RUM or Core Web Vitals to see what really improved things.
00:33:14 - Anthony Campolo
One thing I did learn that was interesting from this whole thing is that when I tweeted some stuff about this, someone from the Lighthouse team, I think, sent me a message and they're like, "Hey, have you seen this? Have you heard about the user flow thing?"
00:33:28 - Matt (filling in for Scott)
Yes, that's the recorder. And now you can go through... So it used to be Lighthouse would only let you record first load. I actually wrote a column four years ago saying the problem with Lighthouse is it only measures first load. You can't look at the whole flow a user takes and record those types of things, especially in a single-page application where they load, and the first load of a single-page application takes a while, but then they click through five different pages and it's really, really fast. But Lighthouse wouldn't capture it because it would load each of those transitions as independent page loads. So it penalized some of the fastest sites because of that. So that user flow recorder, I think, is what they're referring to, is definitely an improvement. I'm excited they did that.
00:34:29 - Anthony Campolo
I'm just getting all these messages and all these tweets and stuff about the latest things. I'm a bit distracted here.
00:34:36 - Matt (filling in for Scott)
No, no, no. You mean the latest with Remix?
00:34:41 - Anthony Campolo
Yeah, yeah, yeah, yeah. Because now Fred K. Schott is tweeting about it. So yeah, it's a... Oh, Twitter, man.
00:34:47 - Matt (filling in for Scott)
Oh, yeah. What was Fred's take, if you were to summarize it?
00:34:52 - Anthony Campolo
Yeah. So Fred was like, "It has been zero days since the Remix team started a fight with another open source project on Twitter and then deleted their tweets."
00:35:04 - Matt (filling in for Scott)
Okay. So I'm surprised you didn't use the Simpsons meme with the zero days since incident. So anyways, that's the performance stuff. We're just past the halfway point. Let me see if there are any questions, then I'll do what I call our normal station break.
00:35:27 - Ishan Anand
I think we're good.
00:35:28 - Matt (filling in for Scott)
Okay, great. So if you're just joining us, welcome to JavaScript Jam Live. JavaScript Jam is a podcast for front-end and full-stack developers. Anything web development or JavaScript is on topic. This is basically, you know, we like to call it an open mic. Anyone from the audience is welcome to raise a topic, is welcome to ask questions or comment on something we're talking about. And we love to be audience-driven as much as possible. Whether you're a beginner or an expert, we want to hear from you. Feel free to raise your hand. There's a button in Twitter and we'll bring you up to the stage, and we'd love to hear what other folks are interested in hearing about. And we love it when the audience actually asks the question and somebody else in the audience is able to answer it. So let's move on then. The other thing that caught my attention, and this is actually going back two weeks ago, is Google postponing their third-party cookie phase-out. And it's not clear if people are aware that third-party cookies are going away. Curious if our routine speakers had a thought, or did you notice this, or thought it was not really impactful?
00:36:48 - Matt (filling in for Scott)
It's not really impactful.
00:36:49 - Anthony Campolo
Sorry. About what?
00:36:51 - Matt (filling in for Scott)
The phase-out. Google is delaying its third-party cookie phase-out. But there's definitely this clear pressure to eventually phase out third-party cookies. And they've done a bunch of things around FLoC and Fledge. I don't know how much people have been following this. We can go into more detail, but...
00:37:07 - Anthony Campolo
I mean, I think it would be great. Great. I think third-party cookies... I don't want sites to be able to track me around other sites. I don't know why anyone would ever want any company to ever be able to do that.
00:37:16 - Matt (filling in for Scott)
So yeah, interesting. I like that goal in principle, but to me this is a scary place because there's so much on the web that I feel depends on third-party cookies.
00:37:38 - Anthony Campolo
And is that stuff good, or that anyone wants?
00:37:41 - Matt (filling in for Scott)
Oh, it's a good question. Some of it, yes, and some of it, no.
00:37:44 - Anthony Campolo
So give me the yes. What's the yes?
00:37:48 - Matt (filling in for Scott)
So the yes is the ability of shared logins. The other yes is the more controversial one, which is the ability to have better-targeted advertising that supports some subset of the web ecosystem. And there is an argument to me that advertising drives too much of the web ecosystem. But advertising is...
00:38:20 - Anthony Campolo
fine as long as it's opt-in. If people can say, "I want to opt into being tracked, all of my behavior to be tracked all across here, and that people can sell me better stuff," that's great. That should be opt-in and opt-out.
00:38:33 - Matt (filling in for Scott)
Got it.
00:38:34 - Anthony Campolo
And the first thing about shared login, I'm sure that can be accomplished without cookies somehow.
00:38:38 - Matt (filling in for Scott)
Yeah, they're going to find ways to do that. I'm confident they'll find a way to do that. But there's a good episode of Benedict Evans's podcast where he's like, well, you start with this idea you don't want to be tracked, and then he walks it down the line and he's like, well, look, at some point it's just Procter & Gamble being like, "Well, I just want to show ads for diapers to people who are most likely to want to buy them." And that's what they're trying to do. They're not necessarily trying to spy. That's why that ad follows you around, and that feels a little less nefarious. And then the other concern with third-party cookies going away is the proposals to replace it. Like FLoC and Fledge, a lot of third-party advertising providers have felt like it benefits the existing incumbents and locks them out. And so those have been some of the objections to it. I don't know if other folks have thoughts, concerns, or if this is something that, as a developer, you're like, "I don't think about this. Just tell me what to implement, I implement it."
00:40:00 - Matt (filling in for Scott)
So is the FLoC standard, is that still on the table? I thought that was not being considered anymore. No, FLoC has been... Yeah, FLoC is going away. And now it got replaced with something else called Fledge. And to be honest, I haven't been following closely enough. I think Fledge might also be off the table. I'm not sure what's going to replace that. But you're right. Thank you for the clarification. FLoC is going away.
00:40:38 - Speaker 5
We have... Looks like we've got Theo. Oh, well, we had Theo in here. I was gonna say, he might have some spicy take on Remix there, but...
00:40:47 - Matt (filling in for Scott)
Oh, well, yeah, that would have been good.
00:40:49 - Speaker 5
Just for a second.
00:40:49 - Anthony Campolo
He.
00:40:50 - Speaker 5
Guess he's gone.
00:40:50 - Anthony Campolo
Never mind.
00:40:51 - Matt (filling in for Scott)
That definitely seems to be the topic of the day.
00:40:55 - Speaker 5
One thing I wanted to add was, maybe this is not really that advanced of a take here, but it seems like Remix is kind of able to turn serverless into serverful in a way. Let's say...
00:41:14 - Matt (filling in for Scott)
Let's say we used to...
00:41:15 - Speaker 5
And I posted it in reply to this just as part of the thread for the conversation, but this guy made a blog post about Remix, but it was more about Jamstack in general, in my opinion. And he was just saying, yeah, we used to create a separate Express app and then a React app and then put them together and deploy them together, essentially in a monorepo, on Heroku and then get all that to work together and stuff like that. But now we just combine the two in a Jamstack app like Next or Remix and deploy on Vercel or Netlify or something like that. I thought that is a really incredible way of looking at it. And one thing I was thinking about, the difference between Next and Remix, not to get into a shooting war here, but Next plugs the serverless in for you, so you don't have to go out to AWS and create a separate serverless function for each thing you want to call or whatever. It just tucks it right there in the API folder. Whereas Remix kind of creates a serverful environment almost out of...
00:42:22 - Speaker 5
out of these serverless routes, basically. Treating everything like a serverless route, not just the API, whatever. But it's kind of crazy how they wired everything up in such a way that they're able to deploy on all these different places. They completely modularized it in a way that they can deploy on all this different crazy stuff like Architect, which I believe is AWS-centric. I'm not exactly sure.
00:42:52 - Anthony Campolo
But...
00:42:52 - Speaker 5
But Vercel, Netlify, and all these other different hosts, based on some kind of crazy stuff they're doing with Express code. I just thought it was amazing how they managed to manipulate it in that way, to make it so dynamic. I don't know. I just wanted to add that.
00:43:13 - Matt (filling in for Scott)
So just so I understand, you're saying that the way Remix can deploy to both serverful and serverless, you found refreshing compared to how Next does it.
00:43:28 - Speaker 5
I love them both. I think they're amazing frameworks. Yeah, Next is great if you just need some API routes with your React app. Remix is a little bit more involved, like you want to get into it, but yeah, you can connect right to the database right there, sort of like how Blitz does it, but a little bit different. Anyways, no, I wasn't really comparing the two frameworks. I was just kind of making a note of how they manipulated the serverless routes in such a way to almost treat it like a serverful environment, like creating everything dynamic. Not just one route, but it can have an ongoing... Or just, I don't know, maybe I'm off in the weeds. You can just disregard everything.
00:44:18 - Matt (filling in for Scott)
No, no, no. I want to...
00:44:20 - Daniel
No, I think it's good. I agree with you. I feel like they do a really good job of extracting it away. When you use Remix, it definitely feels more complete. I use Next because it's what I prefer. But at the same time, when using Remix, it definitely feels like a more complete solution because of that and the ability to be dynamic between the different strategies you can use. I feel like you can accomplish the same things with Next, of course, but out of the box, Remix has a very much you're up and going feel. It's much more streamlined. They do a good job of extracting it away.
00:44:55 - Speaker 5
Thank you. You saved me.
00:44:58 - Matt (filling in for Scott)
It feels to me like Remix came from people who still liked classic server architecture with a CDN in front of a server in front of a database. And Next had some of that, but also tried to incorporate elements of Jamstack, and that muddied the model a little bit. Do you feel like that's what led to what you're describing here, or am I extrapolating too strongly?
00:45:36 - Speaker 5
Maybe I don't even know what I'm talking about. I just feel like everything is dynamic. The difference is, if I were to go onto DigitalOcean and install Node.js and whatever, and put up an Express app with a Remix app in front of it, and then combine the two with web... whatever that's called. I even forgot the name of it. What, webpack? If I were to do all of that, I feel like I get the exact same result if I just spin up a Remix app. I can hit any route I want, just as if I were hitting anything in Express. I feel like it's the same effect as running a fully serverful application as opposed to hitting one single API route.
00:46:26 - Ishan Anand
Right.
00:46:26 - Speaker 5
Which maybe, like I said, is probably not the most complete take. Maybe I don't fully understand the space as well as I should, but it just feels like everything is all dynamic all the time as opposed to just in one place.
00:46:43 - Daniel
No, I actually agree with you. I think if you're used to how it was before, actually coupling Express with React, Remix does feel a lot more natural, at least from my experience now. I was an early adopter of Next before it was super popular, but it really solved a major challenge at the time. It was also more difficult to deploy than other Jamstack methods because back then Netlify and Vercel were really just promoting their use with Gatsby or other static page generators, not so much server-side rendered. But now that they're all supporting it, it opens up the area for both. But I do feel the same way about Remix, very similar to how you described it. And I think it's probably just from what we experienced before and it transitioning over. I feel like when you're in Next, you're building a lot more than you are getting out of the box, having things ready to go. Remix definitely feels like it's good to go right there and abstracts a lot of it away.
00:47:47 - Matt (filling in for Scott)
I think then we're saying the same thing. I don't know if my extrapolation is accurate as to...
00:47:52 - Daniel
Yeah, I agree. I think so. I think we're all saying pretty much the same baseline. I think that, you know, it's kind of like, you know, you use Blitz as a reference. That's when it really clicks for me. Blitz feels like Rails. You get up and going, you follow the docs, you don't have to worry about maintaining anything. It's just ready to go. Whereas Next, you are building out each layer of it. Even though you do have a framework behind it, it's not a complete framework. It's definitely using more of the React mentality of build your own solution as you go, unless you're plugging into microservices along the way. Just my take on it, though.
00:48:31 - Matt (filling in for Scott)
Blitz is an interesting touch point. We've had him on JavaScript Jam, the podcast and JavaScript Jam Live in the past. I think he was actually one of our first speakers for when we migrated over to Twitter Spaces. I'm curious if folks are using Blitz in production and what their experience has been with it, because that promise of we're going to give you the equivalent of Ruby on Rails, but it's entirely JavaScript, was just really exciting. It's something Redwood also is promising.
00:49:09 - Anthony Campolo
What?
00:49:09 - Matt (filling in for Scott)
Redwood? Yeah.
00:49:10 - Ishan Anand
Huh.
00:49:11 - Daniel
Yeah. I was about to say we should definitely open this up to not only Blitz but Blitz and Redwood. I love using Redwood. I haven't used it in full production yet, but just walking through it and using it, it definitely feels the most similar to Rails without being so coupled to anything particular. I feel like with Blitz, you're a little bit more tied to what you're using. Maybe it's changed since the last time I used it.
00:49:35 - Anthony Campolo
There's a problem with this whole conversation, which is, yes, you can't talk about Blitz at all right now because Blitz is going to change. The Blitz that was will not be the Blitz that will be, and the Blitz that will be isn't really being used or released yet. So there is no conversation about Blitz that is really useful to have right now until you figure out what Blitz is going to be and then make it that. And then we can all talk about what it is.
00:49:58 - Daniel
Yeah.
00:49:59 - Anthony Campolo
What it might be.
00:50:00 - Daniel
Yeah. Brandon has a lot of things going on. So it's been about a year since I've touched Blitz, but I didn't know he was doing a lot more in development.
00:50:09 - Anthony Campolo
Well, there's a new maintainer now who's in charge. Alexandra, people who've been in the Blitz community for a while, they'll know who she is. She also works for Flightcontrol. So someone else has kind of taken it on and is leading it. And I have faith that it's going to be cool and that eventually they're going to figure it out. This whole long transition pivot thing, I think it was a huge, huge mistake and I don't think it's really worked out very well for them. So I've been a huge supporter of Blitz, despite being a quote-unquote competitor to Redwood. When I started FSG, the point was to talk about the fact that there were these two cool new full-stack frameworks. So I'm fully in support of Blitz, but I think having a conversation about it right now is essentially impossible because it does not exist in the state it's going to soon.
00:50:57 - Daniel
Right. I think for me it's really just the comparison to Rails. That's what really brings it up, right?
00:51:03 - Anthony Campolo
Yeah. And I feel like the original Blitz was more Rails-y than Redwood in the sense that Redwood gives you a decoupled front end and back end in the architecture, and it kind of hides it from you to make it feel Rails-y. But the architecture is not actually a monolith. It gives you the illusion of a monolith, whereas Blitz is a monolith.
00:51:27 - Matt (filling in for Scott)
And I think a good example of that, Anthony, what you're just talking about, is that under the hood, Redwood is using GraphQL between the front end and the back end, which means it's easy to stick a native app on top or something like that that might get introduced, and it's just another service your app will talk to. I assume that's still the case. What is the latest on what Blitz will be, from your understanding?
00:51:54 - Anthony Campolo
It's been changing. That's the thing. It first started as, it's going to be a backend toolkit that's front-end-framework agnostic, and there's a whole list of features they wanted to add. Then they kind of walked that back. They were like, no, it's actually still going to be a full-stack framework, but we're going to allow you to swap out Next for other things. So it's not entirely clear exactly what it's going to be. And this goes back to me saying it's hard to talk about because not only is there no thing to say what it is, the thing they're saying it's going to be is shifting.
00:52:26 - Matt (filling in for Scott)
What's the reaction in the Blitz community, in your read? Is it split?
00:52:33 - Anthony Campolo
I mean, some people were really excited about it. Some people were like, "Hey, I got a production app, this is kind of a thing." So then they started saying we're going to make the migration seamless, and that is just like, all right, well, good luck with that. So they're in a really tough spot. I really, really sympathize with them. It's a very tough spot to be in.
00:52:55 - Daniel
I've been using React since its early days, when it first started gaining popularity and Angular was more dominant at the time. I was all about it, but at the same time it was so hard for me to justify switching from Rails to the JavaScript ecosystem. I feel like nothing was as plug-and-play as Rails. Even to this day, with all the attempts that have happened, whether you're comparing Rails and Laravel or whatever it might be, I don't feel like JavaScript has really gotten there with any of the frameworks yet, to where it feels the same. I still feel like I'm better off, especially on a project that isn't guaranteed to scale, popping up Rails or starting a Laravel project than I am adopting the JavaScript ecosystem in a lot of ways because I feel like there is so much work that has to be done just to get the basics under control. And I can't wait for the day to come where it actually does feel like a Rails ecosystem. Whether it's using serverless or monolithic or whatever it might be, just having that ability to quickly MVP a project and really get it out there without having to do a ton of prep work would be huge.
00:54:03 - Daniel
And one of the frameworks that I actually explored early on was called AdonisJS. I don't know if it's still around, but it was very Laravel-esque, and it was one of the better ones that had happened at the time. But it just didn't have the adoption. But seeing Redwood pop up, Blitz, and so on and so forth, it's kind of exciting to see it go in that direction. It's just taken such a long time to get there.
00:54:29 - Matt (filling in for Scott)
Do you think we will get there? It feels like they used to say artificial intelligence is always five years away. I thought it would have happened by now, honestly. When I saw Redwood and Blitz come out, I was like, finally. I felt like we needed this yesterday. And it's kind of surprising that the JavaScript ecosystem hasn't met that challenge. And I wonder if there's something fundamental there.
00:54:58 - Daniel
I think it's cultural. I really do. I feel like a lot of it is, at least in the early days, it was, let's do this without opinions. Let's get away from Angular and its opinions. And then it was, okay, now we need opinions in order to create structure and consistency and to rapidly develop. And then these frameworks pop up, and every time a new framework came into the ecosystem, it would get abandoned. Then the opinions would get rewritten, and then it would be like, we don't want to follow opinions, we want to do this free-form. Everything shouldn't be black box or pre-done for you like it is in Rails. Because Rails is very much a black box. If you're really using the ecosystem for what it's worth, half of your code, you're not even really sure what it's doing unless you're diving into the different gems. And I feel like the culture in the JavaScript world is so different. People want to go under the hood. They want to control what's happening. Everything is so different than it was in Rails culture.
00:55:56 - Daniel
Rails culture wasn't about that. It was about getting the solution to market as fast as possible and worrying about scaling later. Laravel was the same way. It was, how do we get an admin dashboard up today? It wasn't about how to do this with the most performance-grade modern technology. It just didn't work that way. So I feel like the ecosystem and the culture kind of fight against each other in a lot of ways, and I'm not sure if it will get there, but I hope that it does because I enjoy JavaScript significantly more than the other two.
00:56:26 - Matt (filling in for Scott)
Interesting. Anthony, I don't know if you have any additional thoughts. We've got only a few minutes left.
00:56:31 - Anthony Campolo
But you know, yeah, I always have a million thoughts and things about all this stuff. That's why I have a two-year-long-running podcast about it. But yeah, I mean, I never used Rails, so I can't really say anything about it and how it relates to other things. All I know is I like using Redwood. I think it's dope. I think more people should use Redwood.
00:56:53 - Daniel
I agree with that. I do. I really enjoy Redwood. I almost called it Railswood.
00:57:01 - Speaker 5
If you don't mind if I add something. I'm with Anthony, I never used Rails either, although I heard people rave and rave about its usability and how quick it is and everything. I know Twitter started with that one thing. I think JavaScript is doing a strangler pattern with older tech like Java, these monolithic apps. Like one of the things, the cloud version of the... what is it called? It's a...
00:57:30 - Anthony Campolo
It's a...
00:57:30 - Speaker 5
It's a reverse proxy. It's an API gateway and it's called... what is that API gateway called that you can do... Gosh, what is it?
00:57:41 - Matt (filling in for Scott)
Name.
00:57:41 - Speaker 5
Anyways, it was saying that the JVM is a monolithic app that doesn't scale and they had to convert everything to JavaScript, and I will think of the name. Sorry. Let me look it up real quick.
00:57:58 - Matt (filling in for Scott)
Sure. Now you've got me on...
00:58:00 - Daniel
Is this related to Spring ecosystem?
00:58:04 - Speaker 5
It was Kong.
00:58:05 - Matt (filling in for Scott)
Kong.
00:58:05 - Speaker 5
You guys know Kong, right?
00:58:07 - Matt (filling in for Scott)
Oh, yeah, yeah.
00:58:09 - Speaker 5
There's like a cloud version of that now...
00:58:11 - Anthony Campolo
Yeah, these guys are gonna know Kong way better than Theo's crowd. You brought this up on another space we were on. I bet you guys know a lot about Kong.
00:58:17 - Matt (filling in for Scott)
Yeah, yeah, yeah.
00:58:18 - Speaker 5
I was looking into that, just like how, if you want to do SSO, for example, if you had multiple sites, let's say you have a back end and it has its own admin page, and you have a front end, there are two independent, let's say, Next sites. I forgot the name of the CMS tool that uses GraphQL... or whatever, but it's for the thing and you have two different...
00:58:43 - Matt (filling in for Scott)
It's...
00:58:43 - Speaker 5
It's what's-his-face's... what's-his-name's... sorry to be disrespectful. It's his Advanced React course and it's called Sick Fits or whatever, and he has the... Anyways, if you guys are familiar with that. But it's two different sites, and I'll say, how do I hit one endpoint and log into both of them? You can do a reverse proxy. I was having trouble because... this could go on a long conversation. I don't want to take the whole thing. But I feel like using something like Kong would be better than trying to, because it's built on top of Nginx but it's got a few different features and stuff like that, so it makes it plug-and-play. It used to be like you have to install it with Docker, Kubernetes, and do all this manual stuff, or on your own servers, whatever. But now they have a cloud that's free to use, and you get a bunch of enterprise... I think you get a bunch of enterprise everything except OIDC, which is login with Google or something like that if you want.
00:59:39 - Speaker 5
You gotta... I think you gotta pay 250 bucks a month for that or something like that. But yeah, anyways, it was saying that they switched from the JVM, from Java, to I believe JavaScript that they're using now because they're saying it just doesn't...
00:59:54 - Matt (filling in for Scott)
scale that well, so that I feel...
00:59:57 - Daniel
I feel like that is crazy. I mean, their scale must be absolutely insane that whatever they're doing on the JVM doesn't scale with the application. From experience, a lot of times, in most of my professional experience as a React engineer, I've typically either been running with a JVM-backed application on Spring or in Kotlin, and the scale is usually pretty wild. So I'm curious what happened to make them do the rewrite. I'm sure it's a unique situation, but I don't know. I'm probably biased, though. I'm a big fan of Kotlin.
01:00:36 - Speaker 5
Okay, I'll find it. It was something I was reading through a bunch of docs. I'll find it and...
01:00:42 - Daniel
then yeah, send it over. I'd be interested to read it.
01:00:46 - Matt (filling in for Scott)
Yeah, same here. I'm really curious because also the behavior of the JavaScript is going to depend on the runtime. I'm guessing they're probably going to use V8, but also the execution patterns of that code.
01:01:02 - Daniel
So yeah, I feel like scaling JavaScript is... I mean, serverless has made it drastically easier. And I will say, when I was primarily focused on engineering, serverless was still new and still being tested. So my experience is a little more limited in that area. But it was the last choice we typically made, was going completely backend-based, everything JavaScript, just because of the scaling issues that we would have with it. So I always love reading about it now because I see how much impact serverless has created for the JavaScript ecosystem, especially on the back end, to make it scalable. But I love hearing the comparison these days.
01:01:41 - Matt (filling in for Scott)
Well, they've definitely improved the runtime behavior of JavaScript. It's grown by leaps and bounds, especially depending on if you're running it as isolates or a variety of other ways to run it. I definitely want to check that out. We're actually overtime for me. I'll let Matt keep us going if he can. But other than that, I will have to sign off and thank everyone for participating in JavaScript Jam this week. And actually, I won't be here next week. I was about to say I'll see you next week, but Scott will be here, and I will hopefully see you in a future episode of JavaScript Jam Live.
01:02:27 - Daniel
Sounds good. And I'm also jumping as well. So it was a pleasure having all of you, and thank you. Can't wait to hear from you next week.
01:02:33 - Matt (filling in for Scott)
Yes. Thanks, everyone. Thanks, everyone.
01:02:38 - Daniel
Bye.