Signals FOMO ChatGPT and Wordpress

Episode Description

JavaScript Jam Live discusses ChatGPT for developers, WordPress performance roadmap, conference access for students, signals, and React server components.

Episode Summary

This JavaScript Jam Live episode covers a wide range of web development topics, starting with the weekly newsletter highlights including ChatGPT's usefulness for programming questions and TypeScript documentation. The conversation shifts to Dev Agrawal's initiative to help college students attend tech conferences through sponsorships and partnerships, sparking enthusiasm from the hosts about scaling the effort. The panel then examines WordPress's 2023 performance roadmap, with Henri Helvetica providing insider context on how WordPress's open-source governance slows but strengthens its development process. A substantial portion of the show centers on signals as a reactivity primitive, with Dev explaining how signals enable fine-grained DOM updates without re-rendering entire components. The discussion evolves into a deep debate on React server components, where Theo Browne passionately advocates for the mental model shift they enable—treating server and client as a unified component abstraction rather than separate layers. Ellery raises practical concerns about hydration and time-to-interactive for e-commerce sites, which leads into a broader conversation about resumability, Qwik's approach, and whether hydration is fundamentally flawed or just contextually problematic. The episode closes with a lively exchange about Angular's change detection, RxJS, and how signals may become the default reactivity model across frameworks.

Chapters

00:00:00 - Introduction and Newsletter Highlights

Scott and Anthony open the show with their usual Wednesday welcome to JavaScript Jam Live, introducing themselves as co-hosts from Edgio. They quickly dive into the week's newsletter topics, touching on signals, ChatGPT programming examples, and the WordPress 2023 performance roadmap, while noting a missed mention of Brad Traversy's new three-hour Web Development 2023 practical guide.

Anthony explains his approach to curating the newsletter, focusing on open source developments, web performance, and wildcard topics like AI. He shares his experience using ChatGPT as a more accessible alternative to TypeScript documentation, finding it particularly effective for answering configuration questions. The discussion touches on how documentation sites like Astro and Preact are building in AI chat features, though concerns remain about accuracy rates for fine-tuned models.

00:06:27 - ChatGPT Pro, Bing Integration, and AI Tools

Scott shares his experience upgrading to the paid version of ChatGPT, noting dramatic improvements in speed and reliability. Anthony highlights the key advantage of Bing's integration with ChatGPT—its ability to access current internet information and provide source references, addressing one of ChatGPT's biggest limitations around citation and up-to-date knowledge.

The hosts discuss how ChatGPT's capabilities seem to be evolving rapidly, with Scott noting features like site analysis that previously weren't available. They invite audience members to join the conversation, setting the stage for Dev Agrawal to share his news about an Apple engineering interview focused on building internal tools.

00:11:47 - Getting Students to Tech Conferences

Dev Agrawal describes his initiative to help college students and those who can't afford conference attendance get access to tech events. He explains how attending just two or three conferences over two years dramatically accelerated his own career, and he wants to replicate that experience for others. He's been reaching out to conference organizers like React Miami to secure student tickets and discounts.

Scott enthusiastically brainstorms ways to scale the initiative, suggesting creating a foundation, seeking corporate sponsorship from both tech companies and recruiting firms, and leveraging the program for content creation. Anthony connects this to their own upcoming events, and the group discusses practical considerations like university tax benefits, open collective structures, and the potential for a 501(c)(3) entity.

00:18:48 - Signals Explained and Framework Reactivity

After a brief exchange about conference experiences, Anthony pivots the conversation to signals. Dev provides a clear explanation of what signals are—special containers for state that enable fine-grained DOM updates. When a signal's value changes, only the specific DOM node using that value updates, rather than re-rendering entire component trees, which distinguishes signals from other reactivity approaches.

Anthony frames signals as a way to track individual pieces of state throughout an application's lifecycle and asks whether React will remain the only major framework without true signal support. Dev suggests React may have a different vision that could ultimately prove compelling, similar to how React's past innovations were initially met with skepticism before widespread adoption. The conversation briefly touches on React server components as part of React's broader strategy.

00:22:25 - WordPress Performance Roadmap Deep Dive

The panel examines WordPress's 2023 performance roadmap from the newsletter, with Dev noting it appears to mirror optimizations Next.js and Vercel have already implemented. Henri Helvetica joins to provide historical context, explaining that Vercel's performance focus traces back to Guillermo's appearances at Chrome Dev Summit as early as 2016-2017, giving them early exposure to Google's performance initiatives.

Henri offers valuable insight into why WordPress moves more slowly on performance improvements—its open-source governance model means every proposed change gets tabled for community discussion, and features that seem straightforward can take months to finalize. Anthony highlights the enormous leverage of WordPress performance work, referencing Dan Shapiro's point that small optimizations cascade across a massive percentage of the internet, making it some of the highest-impact work possible.

00:32:46 - JavaScript Without a Build Step and ChatGPT API

Theo Browne joins the stage as the discussion shifts to Julia Evans' article about writing JavaScript without a build system, which outlines strategies like using CDN-hosted libraries, self-hosting dependencies, and leveraging ESM. The Deno team published their own take on the topic, though Anthony notes supporting npm may eventually force a build step into Deno's workflow.

Jason raises practical concerns about using the ChatGPT API in serverless environments, noting the tension between long response times and execution limits on platforms like Vercel's free tier. Anthony expresses interest in the Whisper API for podcast transcription, while Dev shares his discovery of an Alexa skill for voice-based ChatGPT conversations. Jason explains the technical differences between the streaming chat interface and the default API buffer-and-wait behavior.

00:44:23 - React Server Components: The Big Debate

The conversation intensifies around React server components, with Theo Browne delivering a passionate case for the mental model shift they enable. He explains that RSCs collapse the separate mental models of server, client, and framework into a single React model where components either get things or do things. Ellery challenges the group on whether anyone is actually using RSCs in production, prompting Theo to describe his extensive work building a T3 stack tutorial in parallel with server components.

Dev adds that Dan Abramov hinted at built-in mutation support for RSCs, while Dan from the audience critiques how RSCs were introduced—arguing the React team could have demonstrated them outside of Next.js to reduce confusion with SSR. Theo counters that Next.js actually makes the demonstration more compelling, and the community has long demanded real-world usage examples from the React team.

00:55:22 - Production Readiness and Framework Comparisons

Ellery articulates the practical perspective of building headless e-commerce sites where performance directly correlates with revenue. He describes hydration as a major pain point—waiting for chunks to load before interactivity kills user experience—and says he's evaluating Qwik, Astro, and Sveltekit as potential alternatives to Next.js. Theo pushes back, arguing that React server components offer the best developer experience he's encountered across all frameworks.

Jason offers a historical parallel to WordPress, suggesting the technically best solution doesn't always win, and React may be becoming the dominant-but-suboptimal choice. Theo responds that server components actually improve React's performance primitives significantly, even if they don't match specialized frameworks. The exchange around use client and use server directives reveals ongoing tensions about developer ergonomics and file structure conventions.

01:05:20 - Resumability, Hydration, and the Future of Frameworks

Suvi joins the conversation to argue that hydration remains a fundamental problem regardless of framework choice, championing Qwik's resumability concept as a breakthrough approach. Dan pushes back, arguing hydration is contextually rather than fundamentally problematic, pointing to Sveltekit's strong performance as evidence. Jason shares his experience building a reporting dashboard with Sveltekit and DuckDB, calling it revolutionary.

Dev brings the discussion full circle by connecting signals to resumability, explaining how reactive graphs could eliminate the need to ship entire components to the client—only the specific DOM update instructions and their signal subscriptions need to be sent. Suvi agrees that signals should be a default in every framework but notes that implementing resumability requires building a framework from scratch, unlike signals which can be retrofitted.

01:19:02 - Angular, RxJS, and Closing Remarks

The conversation takes an unexpected turn into Angular territory, with Dan expressing admiration for Angular's community adopting RxJS. Jason and Dev debate the relationship between Zone.js and RxJS in Angular's change detection, clarifying that they represent different approaches rather than complementary layers. Dev argues that Angular's two-way data binding problems drove developers toward RxJS for maintainable one-way data flow.

Scott wraps up the show with appreciation for the panel and audience, promoting the weekly Wednesday schedule and encouraging participation from developers of all experience levels. Anthony teases next week's guest, Misko Hevery of Qwik, setting up a natural continuation of the resumability and signals discussion. The hosts plug the JavaScript Jam newsletter and upcoming collaborative events before signing off.

Transcript

00:00:01 - Scott Steinlage

Welcome, welcome, welcome. There's Anthony. Let me bring him up here as well. Boom. Right, there you are. Welcome, everybody. Welcome to JavaScript Jam Live.

00:00:20 - Anthony Campolo

Yo, yo.

00:00:24 - Scott Steinlage

Thank you so much. So excited for today. Thanks for joining us, y'all. Appreciate it. Anthony, was it?

00:00:40 - Anthony Campolo

I didn't know what that was going to do. I just hit buttons over here.

00:00:45 - Scott Steinlage

Quite the sound mixer you got over there, buddy.

00:00:47 - Theo Browne

There we go.

00:00:53 - Anthony Campolo

All right, enough of that.

00:00:55 - Scott Steinlage

The first one was the best, though, to be honest. Okay. Great start. Thank you all so much for joining us today. This is JavaScript Jam Live. We do this every Wednesday at 12pm Pacific Standard Time. If you're here, maybe you're new.

00:01:20 - Speaker 4

All right.

00:01:21 - Scott Steinlage

This is where we talk about everything JavaScript and web dev related. It doesn't matter whether you're a beginner developer or you've been doing this for a very long time. We'd love to hear from everybody. In fact, that's where the most value comes from—when people in the audience come up and participate, ask questions, state facts, opinions, it doesn't matter. We'd love to hear it all. So today I'm going to go ahead and do a couple of introductions here.

00:02:02 - Anthony Campolo

And then introduce yourself.

00:02:05 - Scott Steinlage

We'll get into it. Dude, we should have a little sound effect for that, or a button. Like, "introduction."

00:02:12 - Anthony Campolo

Yeah.

00:02:16 - Scott Steinlage

All right, here we go. My name is Scott and I am the technical community manager at Edgio and co-host of JavaScript Jam. And Anthony.

00:02:27 - Anthony Campolo

I am Anthony Campolo, developer advocate at Edgio and also co-host of JavaScript Jam.

00:02:35 - Scott Steinlage

Awesome. Today we're missing Ishan—he has other things he's doing—but he's also another co-host of JavaScript Jam and the VP of Product at Edgio. So what are we doing today, Anthony?

00:02:47 - Anthony Campolo

We're going to talk about what's in the newsletter. Did you read the newsletter? I'm sure you read it every week, right?

00:02:53 - Scott Steinlage

Oh yeah, of course. Come on.

00:02:57 - Anthony Campolo

I mean, I write it. I don't even read everything in it.

00:03:02 - Scott Steinlage

Yeah, there's definitely some good ones in this week though. Let's talk about signals, JavaScript with no build step, ChatGPT examples for programming, WordPress 2023 performance roadmap. That one was pretty cool—some interesting things in there highlighting some of the possibilities, and some of the stuff we've done in past podcasts ties into it. There's some really good stuff in there.

00:03:33 - Anthony Campolo

And then I forgot to tag Brad Traversy. Almost got everyone. He dropped his Web Development 2023: A Practical Guide, which is three hours long.

00:03:47 - Scott Steinlage

We'll have to get it in the next newsletter, but everybody be sure to check that out. As you all know, Traversy always has really good value, so be on the lookout for that.

00:04:00 - Anthony Campolo

He has a Jamstack section, actually. Interesting—I don't know if he's had that in previous ones.

00:04:09 - Scott Steinlage

I don't think so.

00:04:13 - Anthony Campolo

Very cool. But yeah, when I'm putting together the newsletter, what I'm usually trying to do is pull interesting things happening in open source projects, interesting things around web performance, and then some wildcard stuff. Right now ChatGPT and AI in general have just been on my mind a lot, so I included one on how you can use it for programming examples. Honestly, this article is probably not the best example of how to use ChatGPT, but they give some good ideas—like using it instead of Stack Overflow for quick code questions. Something I actually found it to be super useful for, and this might be because it's owned by Microsoft, is that it gives really good answers about TypeScript. Sometimes I have trouble finding or reading the TypeScript docs. I wanted to figure out whether a configuration in my tsconfig was the default or not, so I asked it: is this the default for this setting, and what does it do? And it would tell me what the default is and give me an explanation of what it is.

00:05:18 - Anthony Campolo

I found it easier than just reading the tsconfig reference guide.

00:05:25 - Scott Steinlage

That's good. Yeah, it's like a 10x search feature. It's awesome.

00:05:33 - Anthony Campolo

What's funny is a lot of different docs are now building this in. Astro has built a way to do this, Preact has built a way to do this. There's also some pushback against it—DanJitan tweeted something about AI chat not being the future of docs or something like that.

00:05:56 - Anthony Campolo

The problem right now is that we don't have the ability to fine-tune these models enough to ensure they actually give the right answer to 100% of docs questions. You probably get like 90 to 95% correct, which is pretty good, and people make mistakes in docs just as humans do. So I think there's a lot of potential there for asking a question to a documentation website and just getting a natural-language answer back.

00:06:27 - Scott Steinlage

Yeah, no, that's really good. I used ChatGPT a month ago because I was on paternity leave. When I came back, I used it again yesterday.

00:06:40 - Anthony Campolo

Did they give you access to Bing yet?

00:06:44 - Scott Steinlage

No, I haven't messed with Bing. But I will say this—I did pay for the Pro version of ChatGPT and it is dramatically faster and so much better.

00:06:55 - Theo Browne

Yeah, that too.

00:06:56 - Anthony Campolo

Anytime you want, it doesn't crash.

00:06:57 - Scott Steinlage

That's the beautiful thing. Anytime I'd ask it anything too lengthy, it would just cut off. Like, I can't continue.

00:07:04 - Anthony Campolo

I would get into conversations where I'd go back and forth five times and then it would rate-limit me, because I have very in-depth conversations with ChatGPT.

00:07:13 - Scott Steinlage

Yeah, that's awesome.

00:07:17 - Anthony Campolo

What's crazy is that Bing is able to actually reach out to the internet, which means it can give you up-to-date information. It doesn't say, "Sorry, my memory ends in 2021." It can reference current information and it actually gives you a reference—when it says something, there's a little link saying this is where I got this from. I think that's ChatGPT's biggest problem right now: it just tells you stuff and you're like, but why?

00:07:43 - Scott Steinlage

Yeah. Before—and maybe this is just part of the Pro thing, or maybe it's just because they had a new release—for ChatGPT, whenever I'd ask it to go and analyze a site for something particular,

00:08:04 - Anthony Campolo

it can't do that at all.

00:08:05 - Scott Steinlage

Right, it said it can't do that. But guess what? It can now, because I asked it last night to do something and it analyzed it for me.

00:08:13 - Anthony Campolo

What did you give it and what did it give you back? Sometimes it can basically read the URL and get the idea of what the website's about.

00:08:22 - Scott Steinlage

Yeah, maybe that was it. I don't know. But either way, it's cool. I'm really enjoying it and the things that are coming out of it. It is so much faster—it's really mind-blowing. All right, moving on.

00:08:41 - Anthony Campolo

Does anyone in the crowd want to join?

00:08:44 - Scott Steinlage

Yeah.

00:08:45 - Anthony Campolo

Inviting you to speak, because you always have interesting things to say.

00:08:48 - Scott Steinlage

But yeah, let's hear Dev's big news, because I know he has some big news he could share with everybody. It just happened, right?

00:08:59 - Anthony Campolo

We got a couple requests.

00:09:00 - Scott Steinlage

Yep.

00:09:10 - Jason

Oh, hey. I also—

00:09:12 - Anthony Campolo

What is up, Jason? Long time no see.

00:09:14 - Jason

Yeah, I'm not as exciting as Dev here. I was just—

00:09:19 - Scott Steinlage

No, we love you.

00:09:20 - Jason

Don't fill the void until he gets here. No, just kidding. Hey, how's it going, guys? I just came up because you asked for somebody to come up.

00:09:29 - Scott Steinlage

Yeah, man.

00:09:30 - Ellery

I don't know how much—

00:09:31 - Scott Steinlage

Thanks for joining us up here. Feel free to speak up anytime. I think I saw something about Dev—he had an interview coming up with Apple, which was interesting. I wonder if he did it.

00:09:45 - Anthony Campolo

Or he also—this might not have been super recent—but I saw him make an announcement about something really cool he did with some conferences.

00:09:56 - Scott Steinlage

That's cool. Yeah.

00:09:57 - Dev Agrawal

Can you guys hear me?

00:09:58 - Scott Steinlage

Yeah, absolutely.

00:10:02 - Dev Agrawal

Perfect. Let me know if there's an echo. Thank you for letting me up to speak.

00:10:08 - Theo Browne

For sure.

00:10:09 - Scott Steinlage

Yeah, go ahead.

00:10:10 - Anthony Campolo

What's going on in the world of Dev?

00:10:13 - Dev Agrawal

Not much. I basically just got off the call with the Apple person and I think it's going fine. I don't know how much I can talk about it, but it's going fine.

00:10:26 - Anthony Campolo

Just big picture—can you say vaguely what kind of role it is? Is it more engineering, more DevRel, or do you not really know?

00:10:36 - Dev Agrawal

It's definitely not DevRel. It's a lot more engineering, and it's mostly building internal tools—not any Apple products—so there's more freedom for implementation and stuff.

00:10:49 - Anthony Campolo

So like Retool?

00:10:53 - Dev Agrawal

Kind of.

00:10:55 - Anthony Campolo

I don't think Apple probably uses Retool, but the idea is you're creating back-office things—forms-over-data stuff.

00:11:05 - Dev Agrawal

Yeah, something like that. It's more like an internally-made, cruder version of Retool. And other things.

00:11:13 - Anthony Campolo

Cool. Well, enjoy never being able to talk about it in public for the rest of your life.

00:11:18 - Dev Agrawal

Yeah, that's the biggest turnoff for me about this job.

00:11:24 - Anthony Campolo

It's like you're on the Manhattan Project now. People can assume whatever they want about what you're doing.

00:11:31 - Dev Agrawal

Yeah, and I love jumping on these spaces and talking about stuff way too much to work on secret projects like that.

00:11:40 - Anthony Campolo

Can you talk about what you did with conferences? I think you were sponsoring people or something like that?

00:11:47 - Dev Agrawal

Sure, yeah. Is that a good topic for this space?

00:11:52 - Anthony Campolo

I mean, this is something I actually wanted Scott to hear about. I don't know if he's seen this, but we're setting up our events for the next couple of months, so this is super relevant to us. And you're collaborating with some conferences we're already collaborating with, like React Miami.

00:12:09 - Dev Agrawal

Sure, yeah. I can talk a bit about it. Basically, for the last two years or so I've been trying to work on ways to get college students—or really any sort of student, or anyone who cannot afford to attend conferences—to conferences, so they can build up their networks, learn about stuff, and advance their careers. After going to just two or three conferences over the last two years myself, my career has exploded beyond what I could imagine. I simply want other people who can't afford it to have that experience, because I also couldn't afford it and I did it through the university. So the biggest challenge is just trying to find sources of funding to get people to these conferences. The main mission is just that: get people to conferences so they can level up their careers.

00:13:16 - Anthony Campolo

Yeah. Hopefully the wheels are turning.

00:13:18 - Scott Steinlage

Oh, totally, dude. I'm thinking of all these different things you could do. First of all, maybe we should create a foundation if there isn't already one. Second, if there is already one, we should find them and work with them because maybe they already have some things rolling. Third—or actually this should be second—reach out to companies who want to sponsor this thing, just like they sponsor events. I'm sure a ton of people would be on board. They're constantly trying to maintain a pipeline of people to hire. If they have college kids coming out fresh and ready to roll, that's great. And companies that would probably be willing to put money into this would also include headhunter recruiting firms. I bet they would be all for it—helping these people, giving them the tools and networking experiences to change their lives and help the next generation. I think that's awesome.

00:14:30 - Anthony Campolo

And we can make some content.

00:14:32 - Scott Steinlage

Oh hell yeah. We can create stories, and

00:14:37 - Anthony Campolo

they can get their name out there and be like, hey, I got interviewed at this cool thing.

00:14:41 - Scott Steinlage

Oh yeah. And it would help these events too. I know some events do have something kind of like what you're talking about.

00:14:51 - Anthony Campolo

For example, many conferences do have scholarships for a wide array of reasons. It sounds like what Dev's doing is going to the students directly, instead of the events saying, we have a scholarship.

00:15:08 - Scott Steinlage

Yeah, I love it.

00:15:11 - Dev Agrawal

I'm actually doing both. Some conferences do have student discounts, but for the ones that don't, I reach out to them. For example, I reached out to Michelle from React Miami and Clark from that conference because they didn't have a student ticket—but they did say, if you want some sort of special discount for a special reason, reach out to us. I told them about this whole thing and both of them were pretty supportive. So it's not just that we're working with companies willing to sponsor conferences—organizers also want to be involved.

00:15:49 - Scott Steinlage

Oh, I'm sure they would.

00:15:51 - Theo Browne

That's awesome.

00:15:52 - Anthony Campolo

Are you talking with Joe Eames for ng-conf?

00:15:56 - Dev Agrawal

Not yet. I have a very small scope right now.

00:16:03 - Anthony Campolo

Well, if you want to widen your scope, we know some people who know some people, 100%.

00:16:09 - Dev Agrawal

Yeah, I just don't have time right now. But at some point I definitely want to scale this out a lot more. Right now it's all scoped to the University of Cincinnati and we're limited by the funding we get from the university as a student org. Beyond that, I'm sure there are fundraising opportunities outside to scale this out. I just need to find more time to invest in it, or more people to work with.

00:16:41 - Scott Steinlage

Yeah, this could almost be an Open Collective thing too, maybe. I don't know—even though it's not open source, maybe there's another way to go about it.

00:16:51 - Suvi

Yeah.

00:16:52 - Anthony Campolo

It just means creating a legal entity that people can hand checks to that doesn't look sketchy on their taxes. There are many ways to accomplish that these days.

00:17:01 - Scott Steinlage

501(c)(3) or whatever. Yeah.

00:17:05 - Dev Agrawal

So far we've been leveraging the university for that because, being part of the university, we get tax benefits and can have a bank account. But obviously, as soon as we make this into a foundation, it's a whole different beast.

00:17:20 - Scott Steinlage

Yep, makes sense.

00:17:24 - Anthony Campolo

Fascinating. Thanks for sharing that. It's super cool and very in line with what we believe in here—enabling people to break in and get their first start. I remember my first conference was Remix Conf last year. That was my first in-person conference. I got into the industry during the COVID times, and that was the first time me and Ishan and Scott all got together, first time with Michael Chan, Austin Crim, Chris Burns, my podcast co-host. So it was so great. It was this whole crew of people who had known each other for years and finally got to meet up.

00:18:06 - Dev Agrawal

Yeah, I've yet to have that feeling. When I first went to conferences I didn't know anyone—I knew of people, but I didn't have friends. So I think this year when I start going to conferences, I'm going to have those feelings.

00:18:20 - Anthony Campolo

Yeah. So for you it would be like if T3 had a conf—that's what our Remix Conf was compared to...

00:18:26 - Dev Agrawal

Yeah, actually Jamstack Conf was pretty close because a lot of the people I met there, I knew them.

00:18:32 - Anthony Campolo

I couldn't go because of work and I was very mad. Yeah, Jamstack Conf was great, I'm sure.

00:18:41 - Dev Agrawal

Yeah. I'm 100% following up with the two of you offline after this.

00:18:47 - Scott Steinlage

Exciting, man.

00:18:48 - Anthony Campolo

Also, what are your thoughts on signals? Great? Terrible? Meh?

00:18:54 - Dev Agrawal

I love signals. I love reactivity.

00:19:00 - Anthony Campolo

What is a signal?

00:19:05 - Dev Agrawal

Great question. A signal is a container for some piece of state or data. It's a special container—not a Docker image, but you can think of it in that sense. It holds a value inside it. Sometimes you can just pull the value out and see what's there and run some computation. But most of the time, if you use that value in your UI, in your JSX—whatever framework, whether it's Solid or Qwik or Preact—that single DOM node subscribes to that one value. So if the value of that signal changes, the DOM node that the value is going into automatically updates and nothing else updates. That's the key feature of signals and how they distinguish themselves from other rendering or reactivity solutions.

00:20:25 - Anthony Campolo

That made perfect sense. We talk about how you want to avoid global state, but if you think about a UI, by definition it is a global state. You're a single user using a thing, making changes. A signal, the way I think of it, is a way to track that one thing you need to track throughout the whole process. I've seen most frameworks start to build in signals now. Do you think React is eventually going to be the only major framework without true signals?

00:20:59 - Dev Agrawal

I'm not fully sure about that. I think React has a very different vision of what they want the web to look like. They've done it multiple times before—they come out with whatever their vision is, and once more people understand it, everyone starts adopting it. I feel like that might be happening again, where React is trying to prove something to us that we're just not getting. Maybe at some point we'll look at React and say, okay, this is actually much better than whatever else we're doing—which in this case...

00:21:37 - Anthony Campolo

I've been trying to tell people for almost two and a half years now that React server components are the future, and people are still arguing about whether that's the case or not. So I think it's still going to be a while before that whole mess gets figured out. And then maybe they'll tackle reactivity—who knows?

00:21:56 - Dev Agrawal

Yeah, I think everyone is trying to solve the same problems, or similar problems, in different ways. And if anything, it feels like everyone's converging on similar solutions—or solutions that look similar but are different under the hood.

00:22:13 - Anthony Campolo

We're all converging on the thing that will make Alex Russell stop yelling at us.

00:22:22 - Dev Agrawal

Yeah, pretty much.

00:22:25 - Scott Steinlage

Yeah, I went ahead and linked that newsletter at the top, so if y'all are interested, click on it and check it out. Follow along with what we're going to be talking about. We always go off topic too. But yeah.

00:22:39 - Anthony Campolo

By the way, I also want to give Andre a shout-out. One of the articles we featured in the newsletter about the WordPress performance roadmap was something I saw him tweet out, so you're welcome to join and chat about that if you're interested. We're actually hoping to reach out to some people on the team and see if we can get them on to talk about it. I had no idea they have an entire team with a whole manifesto around making performance a first-class thing for WordPress. It was very, very cool.

00:23:13 - Scott Steinlage

Yeah, it was super interesting.

00:23:15 - Speaker 4

You know what, you know how—

00:23:18 - Scott Steinlage

They're focusing on all that. And some things I thought they had already kind of... I know Ishan was talking about this too, how he thought they had maybe already done some of those things or focused on those things, like with images and lazy loading, LCP, avoiding that.

00:23:36 - Anthony Campolo

It looks like they have a group that sets high-level priorities. What you're listing are some of the subcategories that the larger performance group focuses on, which is what it seemed like, right?

00:23:54 - Scott Steinlage

Yeah. Adding fetchpriority="high" to the LCP image in WordPress core—things like that. I thought they had already done that.

00:24:07 - Anthony Campolo

It makes a lot of sense when you think about it, because this is a huge chunk of the internet. This is something Dan Shappir would talk about when working on performance for Wix—you find that one tiny optimization that then cascades across 40% of the internet. So it's actually some of the most high-leverage work you could possibly do.

00:24:27 - Scott Steinlage

It reminds me—I can't remember what it's called—the 80/20 rule. Pareto's law, right? 20% of the work yields 80% of the output.

00:24:38 - Theo Browne

Yeah.

00:24:38 - Scott Steinlage

20% of the work, 80% of the output or something. Yeah, that's cool.

00:24:43 - Anthony Campolo

You get to 80% of the output and then the last 20% takes as long as the first 80%.

00:24:49 - Scott Steinlage

Yeah. There are so many ways people look at that 80/20 rule.

00:24:55 - Anthony Campolo

Well, there's a Pareto distribution, which is kind of a statistical observation of the universe. Dev, what do you know about WordPress or JSON or [unclear]?

00:25:10 - Dev Agrawal

Not much, but this roadmap looks interesting. I have a hot take about this: it feels like they're doing everything that Next.js and Vercel have already done, but for WordPress.

00:25:22 - Anthony Campolo

How do you know Next.js wasn't copying their roadmap?

00:25:28 - Dev Agrawal

Yeah, that's a good question. I don't know. I think Next.js has been on this for multiple years now. And this is the 2023 roadmap, so yeah, I think Next.js has a lot of these things, especially on Vercel. But again, Next.js is not WordPress—it doesn't have the same impact.

00:25:58 - Jason

Are we talking about the roadmap for React or Vercel?

00:26:04 - Dev Agrawal

The WordPress roadmap. It's in the newsletter.

00:26:08 - Jason

Oh, WordPress. Okay. Sorry, I didn't look at that—I was looking at the Deno one, the "you don't need a build step" thing, and I thought that was pretty neat.

00:26:19 - Speaker 4

Yep.

00:26:20 - Scott Steinlage

Yep. For those of you just joining, if you want to check out the newsletter, it's at the top—just link there and check it out. That's what we're kind of going through right now. Henri, what's up, dude? Welcome.

00:26:30 - Dev Agrawal

Hey.

00:26:31 - Henri Helvetica

I'm good. I don't know if—

00:26:32 - Scott Steinlage

Can you hear me? Yeah, I think so.

00:26:35 - Henri Helvetica

Okay, perfect. Sorry, I'm in a basement so I don't know what's going on. I just want to comment very quickly on the WordPress thing. I wasn't going to jump in because I'm pretty swamped right now, but there are a couple of things I want to mention. First of all, the funny thing about whether Vercel is copying WordPress or vice versa—if you go back and look at some videos, Vercel has been tuned into performance for a little while. I think I realized it after Guillermo had been invited to speak at Chrome Dev Summit. For those who had never been, even though it's called Chrome Dev Summit and it's a conference about everything they're doing, it did feel like a performance conference, which is why I loved it so much. It's not back yet, but going back, I'd seen that Guillermo had been on stage talking about some of the stuff they were working on.

00:27:44 - Henri Helvetica

This might have been even 2016 or 2017. Anyway, that being said, I think they had very early exposure to what Google was doing. So everything they're doing now is really a culmination of a lot of that and whatever came after.

Now, with regards to WordPress—one thing I think people have to understand, and something I did early in my performance maturation, is poke around. I was always curious as to what WordPress was doing and how they were tackling performance. I'll be happy to link some videos for folks to watch. Felix, probably the lead on the team over there, has always talked about this: WordPress is open source, and with that, whenever they make any kind of changes or suggestions, they table it and everyone has a voice. So you'll see things move a little bit slower at WordPress because everyone has an opportunity to mention their concerns, present some data, or talk about their use case. The community, and especially the core of the team, listens. I've been lucky enough to witness some of these conversations. Sometimes you'll have features that you feel like they'll be able to turn around quickly—

00:29:29 - Henri Helvetica

—and then seven or eight months later it's still not done because the conversations are still going. Whereas someone like Shopify will say, okay, this is what we're deciding, and the week after it lands. So I think it's very important to keep that in mind. I've had them on my streams a few times because I'm very interested in how they're moving, how quickly, and what they're able to do. I'll be happy to introduce you to Felix and the rest of the team—Thierry, Andrew, and the others. Very interesting conversations as to what they're doing over there.

00:30:21 - Jason

Thanks for the link, Henri. I did check it out. It looks cool. I read an article earlier this morning by somebody who's breaking up the PHP functions of WordPress into serverless functions and packaging it that way so they can handle more traffic. It was kind of an experiment. They were talking about how they were still using FTP and stuff like that instead of Git. It was from some conference or showcase—basically, hey, look, we can use PHP and serverless functions.

00:30:51 - Henri Helvetica

And so on and so forth.

00:30:53 - Jason

People are trying stuff like that out. I just thought it was interesting. And yeah, you can run PHP in WASM too, so potentially you could probably do anything.

00:31:08 - Henri Helvetica

Yeah. And I'll say again—having been in some of these public chats, by the way, they're open to anyone to attend, they have a Slack and you can just sit back and watch—a lot of WordPress users have grown comfortable in some of their workflows and haven't been as quick to adopt and move the way the JavaScript ecosystem has. That has added to what seems like a really slow-moving operation. But there's so much to cover, there's testing, and they're doing their best. This is why I'm supporting them as much as I can by letting people know what they're doing and how people can contribute.

00:32:18 - Scott Steinlage

That's awesome. Thanks for sharing, Henri. Appreciate it. Yeah, the Chrome Dev conference—it would be cool if they brought that back. Like you said, it probably is very much a performance-driven conference, which makes sense with Chrome and V8 and all that they do. Welcome, Theo. Looks like Theo joined us here. Excited to have you, man.

00:32:46 - Theo Browne

Hey, yo.

00:32:47 - Scott Steinlage

Hey yo. So we're just kind of going through some of the stuff in the newsletter, and the last thing we just spoke about—which Henri came up to comment on—was the WordPress 2023 performance roadmap, which has been really interesting. Anthony, what else do we have?

00:33:18 - Anthony Campolo

I'd be curious to get some other people's takes on signals if anyone has them—Jason, or Henri.

00:33:30 - Jason

I'm curious what Theo has to say.

00:33:33 - Anthony Campolo

He's a listener right now. Was there anything else in the newsletter that jumped out at you, Scott?

00:33:49 - Scott Steinlage

The writing JavaScript code without a build system. I don't know, it's kind of interesting. That's Julia Evans' article I think it was, right?

00:34:03 - Anthony Campolo

Oh, looks like Dev's got his hand up. Awesome.

00:34:05 - Scott Steinlage

Let's hear from him.

00:34:08 - Dev Agrawal

I was going to ask about something else, but you brought up the "write JavaScript without a build step" thing. Would love to hear more about that.

00:34:16 - Anthony Campolo

I'll be curious what you're going to say as well. Then we can hit that one.

00:34:28 - Dev Agrawal

Sorry, who were you asking?

00:34:29 - Anthony Campolo

That was you, Dev. What did you raise your hand for? Just so I can table it, at least.

00:34:36 - Dev Agrawal

I was thinking of the second topic, ChatGPT. I don't know if you guys talked about it already—I might have missed it.

00:34:42 - Anthony Campolo

I mean, I could talk about ChatGPT all day. But yeah, the build step thing—last week we highlighted an article from Julia Evans, who's a really great blogger, basically talking about how you can use JavaScript these days without necessarily a build step. If you set yourself up for ESM, you can kind of just put it all in some files and it'll work. And then Deno did their own version of it because for them it's a slightly different thing—they're a backend that allegedly doesn't have a build step. But I feel like if they're going to support npm, they're going to end up with a build step, probably.

00:35:27 - Scott Steinlage

Yeah. She listed the main strategies: search for CDN on a library's website, find a standalone JavaScript file, use unpkg.com to see if the library has a built version you can use, host your own version of libraries instead of relying on a CDN that might go down, and write your own simple integrations instead of pulling in another dependency—for example, she wrote her own CodeMirror component for Vue the other day. The fifth thing would be, if you want to use a build system, use esbuild. And then a couple of other things she mentions but hasn't looked into yet are the TypeScript proposal for type syntax in JavaScript comments, and ES modules generally. But yeah, lots of talking points there.

If you're in the audience—thank you all so much for joining us today.

00:36:48 - Scott Steinlage

This is JavaScript Jam Live. We do this every Wednesday at 12pm Pacific Standard Time, where we talk about everything web development and JavaScript related. Whether you're a beginner or advanced, it doesn't matter. We love to hear from everybody, so feel free to raise your hand and request to come up on stage—we're more than happy to have you. You can ask a question, state a fact, opinion, whatever it might be. We'd love to hear from you. Jason, what's up? You were raising your hand there. Yeah, the topic of ChatGPT.

00:37:25 - Speaker 4

I was wondering if anyone has been playing around with the actual API to build things, since they announced the new ChatGPT-based model that costs a lot less and is supposedly super fast. The thing I was running into, just playing with some responses that take longer, is the intersection between edge functions, serverless environments, and how long ChatGPT can take to respond is starting to be concerning. Can you run a serverless function that might take 20 or 30 seconds to execute? You might be bumping up into the free tier limit of Vercel, or having serverless functions that cost a lot of money to run because they're sitting around waiting for responses from ChatGPT—since it does internally stream the response back as it's writing out its answers. Just some stuff I was poking around with over the weekend. I don't know if anyone else has gotten further on that.

00:38:29 - Anthony Campolo

I really want to learn how to use the Whisper API because I want to try transcribing JSJ episodes. I've heard it might actually be capable of transcribing a technical podcast, which... I would pay so much money for that.

00:38:44 - Scott Steinlage

Yeah.

00:38:46 - Speaker 4

I would not be surprised.

00:38:50 - Anthony Campolo

What were your ChatGPT thoughts, Dev?

00:38:56 - Dev Agrawal

I don't have too many thoughts on ChatGPT. I'm not using it as much as I should be, honestly.

00:39:03 - Anthony Campolo

I'm sure you've got some thoughts. You've been seeing a bunch of my tweets about it.

00:39:08 - Dev Agrawal

Yeah, I've seen some tweets, but for some reason I don't actively think about it too much. I don't know why.

00:39:16 - Anthony Campolo

I think the best way to approach ChatGPT is first not to think about it as a work tool at all. You should start by asking it actual questions you have about life and the universe. The first thing I asked it was how do you find a partner—I was curious what it would say, and it gave generic but fairly good advice. Then I asked it whether democracy and communism can coexist in a society. Then I asked it what React meta-framework I should use. Eventually I started getting a sense of what kind of answers it gives, what knowledge it actually has. Then you find ways to get it to tell ridiculous stories and take on new characters, and you discover there's this whole other layer to what's happening in the model. There are archetypal personalities that exist within it that you can summon through prompts. It's the most incredible technology in decades. I really recommend people check out Ethan Mollick.

00:40:19 - Anthony Campolo

He tweets every single day about incredible stuff he's doing with ChatGPT and Bing and all this stuff. I'll share his profile.

00:40:29 - Dev Agrawal

One really interesting thing I found was an Alexa skill that uses ChatGPT, so I can have proper conversations with ChatGPT instead of typing them in.

00:40:46 - Scott Steinlage

Yeah, that's pretty cool.

00:40:47 - Dev Agrawal

It doesn't seem to support all the features. I don't know if it's recording conversation history—it's probably sending each question one by one instead of maintaining a conversation context, which the ChatGPT UI does. But yeah, it's pretty exciting to be able to talk to ChatGPT instead of just typing.

00:41:10 - Speaker 4

Well, that's the feature of the new API—if you want to build it yourself, it does have an array of prompts and responses that you can keep as history. And as long as you stay under the 4K token cap, you can keep that much memory shared between the answer and the response. So you can start to approximate what you get with the user interface.

00:41:43 - Henri Helvetica

Cool.

00:41:44 - Dev Agrawal

Really hoping someone builds that.

00:41:46 - Theo Browne

The only—

00:41:47 - Scott Steinlage

What I was getting at with my—

00:41:49 - Speaker 4

—question, or my prompt, so to speak, was that the current default out of the box—like if you just install the OpenAI client off npm, it's basically just a wrapper on top of Axios for the HTTP requests—is a buffer-and-wait until you get the whole response. The out-of-the-box experience as a developer is you have to wait for the whole thing to come back before you get anything, whereas with the user interface you get it streamed to you. So you have to jump through some hoops. I think there are some developers starting to put out some code on how to do this using HTTP streaming—essentially taking the responses in blocks as they come off the fetch request and piping them over to the response socket. Anyway, hopefully someone will write a decent client that can just do that out of the box before too long.

00:42:50 - Anthony Campolo

OpenAI has a DevRel person. That's something they should be working on. Maybe they should have ten DevRel people.

00:43:00 - Speaker 4

It looks fast, right? If you wanted it to generate a couple of paragraphs—meaning of life questions and answers—it looks fast on the chat because it's giving you updates every few phrases. Whereas if you made the same request to the API, it would just sit there and wait until it had the whole paragraph, which takes 10 or 15 seconds to generate. Anyway, this is the user experience difference between what you get out of the box as an API developer versus what you get from the client if you just sign up for ChatGPT.

00:43:40 - Scott Steinlage

So I shared up top as well—Logan GPT. I don't know if you guys have heard of him, but he was in my feed.

00:43:49 - Anthony Campolo

Yeah, that's what I was talking about.

00:43:50 - Scott Steinlage

Yeah, is that the one? Okay, got it. Well, anyway, I followed him not even a couple of weeks ago and thought it was a great thread. He's actually a DevRel person for OpenAI, so probably a great source. Check him out.

00:44:12 - Anthony Campolo

He was the first guest on Swyx's new AI podcast.

00:44:15 - Scott Steinlage

Well, maybe we should get him on here—we talk about ChatGPT so much.

00:44:23 - Anthony Campolo

Yeah, right. Anything else? Does anyone want to talk about things they found interesting happening in the world of web dev or JavaScript? It doesn't have to be from the newsletter—it could be anything.

00:44:39 - Dev Agrawal

Everyone's talking about React server components.

00:44:43 - Anthony Campolo

Yes, they are. I'm glad. It's about time. I think people are still trying to get it because when it was first announced, they were like, this is another thing that's going to take three years, so I don't need to worry about it right now. And now it's three years later and everyone has to worry about it.

00:45:06 - Jason

Yeah, RSC is exciting. Another sleeper thing is Bun—the Bun execution environment. One of Theo's friends has some kind of framework. I found it through Theo. This person created Elysia. Yeah, it's amazing.

00:45:29 - Anthony Campolo

I ran into Dan. What's up, man? And also Ellery, welcome to the stage.

00:45:34 - Scott Steinlage

Thanks.

00:45:35 - Ellery

Yeah, I just wanted to hear more about RSC and if anyone's actually using it or if it's just promising vaporware.

00:45:45 - Anthony Campolo

Next is using it.

00:45:49 - Ellery

Not sure that counts.

00:45:53 - Anthony Campolo

The number one React framework doesn't count?

00:45:55 - Ellery

Well, I mean using it in practice, not just the fact that they have it.

00:45:59 - Anthony Campolo

Yeah, I get what you mean. Theo is about to come up and talk about React server components. He can school you.

00:46:09 - Dev Agrawal

My mission was accomplished.

00:46:11 - Theo Browne

You're not the one who baited me.

00:46:12 - Anthony Campolo

It was—

00:46:12 - Scott Steinlage

Ellery, I don't even know what you said, but—

00:46:18 - Ellery

I was very unsure of server components.

00:46:25 - Theo Browne

One sec.

00:46:26 - Dan

Sorry.

00:46:27 - Theo Browne

Yeah, I was very unsure of server components initially. It seemed like a weird way of solving problems I had already solved—similar to, funny enough, how I felt about JSX when I first saw it. Like, we already have templates. Why are we going to make our JS worse? That makes no sense. But then you play with them enough and it clicks, and you realize there's this whole abstraction that we've spent—not necessarily a lot of time day-to-day thinking about, but a lot of our brain cycles on in every problem we solve—thinking about this relationship between the client and the server: what goes where, when, and why.

The magic of server components is the default is now the server. The only time you think about it is when for some reason you need something that only runs on the client. And that mental model shift is massive. The idea that the data flow I'm thinking of through my application now starts from and includes the server—not just from the top of the virtual DOM node down—it really changes what you can do. Because you could do all this with Remix, it just required you to have two or three mental models: one of server-client, one of React, and one of Remix.

00:47:44 - Theo Browne

This is the first time you just have one mental model to do all the same things.

00:47:51 - Anthony Campolo

This is why—

00:47:53 - Ellery

Go ahead.

00:47:55 - Dev Agrawal

I just wanted to also quickly bring up that Dan Abramov casually dropped in a live stream earlier that React is also trying to find a way to include mutations—the mutation story—built into React server components, which I think is pretty exciting and speaks well to the idea Theo presented: that it's just a React mental model now instead of three or four different models.

00:48:21 - Anthony Campolo

So for me, in December 2020 when this was first announced, I was hyped on it and instantly got it because to me, that was already the pitch for Redwood—you have the server, the CLI mostly generates most of the server code for you, and then you have your React client, and that separation was inherent. So I saw that as verification of that kind of idea. And people just didn't seem to fully get it. I thought it was interesting because people didn't seem to get Redwood either. So I'm glad this is finally being pushed into the conversation because I think it's an important mental model to internalize—you just can't get away from it. The server's there. It's a fact of nature.

00:49:07 - Theo Browne

I don't necessarily like this comparison because there are other backend-frontend solutions like tRPC, Remix, SolidStart—all these new solutions that really bring the backend closer to the frontend. The thing that makes server components so different is there isn't a frontend anymore in the traditional sense. It's not bringing backend into our frontend. It's not thinking about backend or frontend. Instead, there are components that get things and components that do things, and you don't have to think much further than that.

00:49:47 - Anthony Campolo

So many times when I explain Redwood, you're like, nah, it's not like this, and then you describe exactly the way I think about it. Being able to add actions—Redwood is able to do all this stuff. The problem is it does it all through GraphQL. It's able to achieve this because of GraphQL itself. This is why all these other frameworks had to figure out a different way to do it, because no one wants to use GraphQL to do it.

00:50:13 - Dev Agrawal

Yeah, this is much closer to the traditional style where you have a PHP app and you add a little bit of jQuery for interactivity. The only difference is that instead of PHP and jQuery, it's both React.

00:50:26 - Theo Browne

And another big part here—I don't want to just harp on Redwood, but solutions like Redwood solve these problems by adding dimensions to them. It added GraphQL as a method to reduce the complexity of the client-server relationship, but it was a trade. They were trading the complexity of GraphQL for the complexity of the client-server relationship, then putting a lot of effort into reducing the complexity of GraphQL because they felt they had an angle to meaningfully reduce it.

React server components were not a good model until they went the async route, when you could actually await server code in your component. I even have a stream way back—I should find the clip—where I remember doing a stream after the original React server components announcement, showing what it should be able to do and complaining that it couldn't, and then went back to tRPC land. Now they've literally done exactly what I asked for. I didn't think I wanted it anymore. And then I started using it and playing with it a lot, and I started realizing how many patterns and behaviors I would do weird things to make work that I don't have to think about anymore.

00:51:35 - Theo Browne

Something as simple as a top nav with your profile picture in it—it's so much easier to block on fetching that data rather than have the pop-in of a scaffolded top nav as you wait to know if you have the info or not.

00:51:53 - Anthony Campolo

Yeah, Dan, what's up?

00:51:55 - Dan

Hey. RSCs are like Astro Islands at home that you can only use with React. No, but they can also—I don't think anyone mentioned this—you can use them down the tree. So in Astro, your client components can't use server components, but supposedly in React server components, your client components can import a server component.

00:52:23 - Theo Browne

Yeah, again, a lot of these other solutions had a lot of the parts. Very little of what React 18 and server components do is truly new in the sense that it's not enabling behaviors or patterns that we couldn't do before, but it's providing primitives that let you do whatever you want. I think that's the biggest issue we're seeing. If you already know Remix or Astro or SvelteKit, you can shape server components so that they're familiar to you. And then you're going to say, oh, this is just the thing I already like, but worse. No—it's the thing you already like, but more primitive and more magical, because now you can assemble it in whatever shape you want. It's so cool how this simple change—you can await server stuff in your component before you return JSX, with the constraint that the component can't be interactive—it can still mount interactive components, it can still do whatever else—that compromise is so powerful on a primitive level. I've been really impressed with the chaotic stuff I can do with it.

00:53:31 - Dan

There are a lot of conceptual issues with how RSCs were introduced, especially in Next, because React already renders on the server using SSR, but this is not SSR. It's a different idea that has enough conceptual overlap that it's going to confuse people. Your Next app both renders client components on the server and renders server components on the server. They also could have introduced RSC with a really great full-stack demo that didn't use SSR—they could have shown how RSCs work outside of the context of a framework like Next—but they didn't. Instead, all they did was have really long, winding Twitter threads. No blog posts after the first one, no YouTube videos until now, just very winding Twitter arguments that don't really introduce the feature in its own context.

00:54:30 - Theo Browne

I don't know how much these features would be understandable without that context. And you also have to consider how much pushback React has gotten forever from people like Alex Russell, saying React has no excuse for not showing us how they're supposed to actually use it. Where's the actual code? Where are the actual examples? How do I actually use this thing? That hesitation is a huge part of why they worked to do this. And on top of that, Next is a really good example of how these things work and it has made it so much more compelling. I don't necessarily think it's the role of the React team to intentionally lower the quality of their demos and RFCs just so we can have more aimless conversations about how it compares to other things.

00:55:22 - Anthony Campolo

So actually, I want to take this back to what Ellery said, because he asked who's using this, and so far no one has said anyone who's using it. Are you using it for actual Ping, or just for stuff you're building for fun?

00:55:36 - Theo Browne

I am using it heavily for stuff I'm doing for content and have every intention of porting multiple things over for stuff we're working on at Ping as soon as I can. The issue is a lot of the stuff we're doing at Ping right now is focused on local development. I could make my own RSC model inside the Vite/Fastify setup I'm working on, but not yet. I'm willing to wait for that. I also want the mutations RFC to come out and to have more ability to experiment there.

That said, something I've been doing a lot is working on a very thorough T3 stack tutorial that I've probably put around 200 hours into at this point—I've gone way too hard on this, making sure I cover everything I

00:56:15 - Anthony Campolo

really need to this year. Like, big tutorial.

00:56:18 - Theo Browne

Yep, first and probably only ever big tutorial. But I just wanted to do it. And one of the things I decided to do was in parallel write the same app I'm doing with the current traditional T3 stack using server components, Next, and Edge specifically. The Edge part's been annoying because nothing supports the Edge yet. But when I worked around all of the issues there, I ended up with a much better developer experience. The thing that shifted my thinking—whenever I go back to working in the page-directory, OG server-side Next version, how much I miss the features of server components. How much I miss being able to just wrap something and fetch the data without having to think about it. There are so many problems where the solution is just make a component the same way it was in React. And that was the aha moment for me: the way I would use components to abstract things and solve problems in React, I can do that for my APIs and my data layer now too.

00:57:19 - Theo Browne

But it's the same abstraction I use every day.

00:57:21 - Anthony Campolo

Are you using tRPC in your example, or the things you do with React server components?

00:57:26 - Theo Browne

I have played with it in a lot of places. I've done some cool things with it. Specifically, you can create a server-side caller in tRPC and then call the same tRPC functions on server and client with the same exact syntax without any issue. It was very fun, especially for the mutation side of things. The reason I'm not doing that is it was an unnecessary abstraction, and the goal of that project was to highlight how much simpler React server components can make things. At that point you've just put two layers in front of calling a function. I might still use it for mutations, and I'm working with Alex to figure out what a tRPC-like thing that truly takes advantage of the new Next and React primitives looks like. But that's a future we're not at yet.

None of this is like, we should be moving all of our production apps to React server components right now—but it's like, in 2015, would it have been responsible to immediately start porting your Angular app to React?

00:58:21 - Anthony Campolo

That would be my question for Ellery—when do you think will be the time? Like, a vague prediction of when you think we'll get closer to this being production-ready.

00:58:32 - Theo Browne

Probably after it's out of beta.

00:58:35 - Ellery

Yeah, obviously out of beta would be great. My primary concern is a big part of what I do day to day is build headless websites for e-commerce companies. They want really fast websites because there's a direct correlation between performance and revenue—if we can take the exact same brand experience and take it off a monolithic platform and rebuild it, there are huge performance benefits that just translate to dollars. The scale and leverage are all there.

But one of the things we struggle with a lot is hydration. Having to wait for chunks to load before certain parts of the app become interactive is really painful. If there were ways to circumvent that without having to re-platform off of Next.js, we would love to do it. But at the same time, I'm also evaluating products like Qwik and Astro and SvelteKit just to see: are any of these really ready? When I have to do the next one of these sites for a client, what should I pick? I'm hoping that Next.js and React catch up, but so far, with developer experience and features like island architecture and so on, right now I'm kind of leaning away from the React ecosystem.

00:59:51 - Ellery

If you put a gun to my head.

00:59:53 - Theo Browne

I will tell you specifically that the thing React wins without any question is developer experience. I play with all of these frameworks—it's kind of my job. With my content platform I've dived deep into all of them with the creators of most of them, and I've gotten far enough to get

01:00:10 - Ellery

most of them to click in my head.

01:00:15 - Theo Browne

I've never had such a strong "I really miss X when I use other things" feeling. With server components, when it clicks, it's like when you got to use TypeScript in React on a side project and then had to go back to working at Ember. It feels like that, but for APIs. You can take that as you will. I think the future looks very performant and very good. But right now, what's mind-melting me is how much I miss server components whenever I can't use them.

01:00:43 - Anthony Campolo

Well, this is the thing. People love React so much they'll use it despite being publicly shamed for it. Jason, you had your hand up for a while.

01:00:50 - Speaker 4

Yeah, I was going to comment on the React server components thing, but the topic of WordPress comes back around because if WordPress is any indication, the solution that's technically best isn't necessarily the one that wins. WordPress has been this albatross around all of our necks—it's the whole reason Jamstack mostly exists. It was the answer to

01:01:19 - Anthony Campolo

Yeah, fully. The definition of Jamstack is the opposite of WordPress.

01:01:23 - Theo Browne

So we still ship Prisma—we don't always go for optimal performance.

01:01:27 - Speaker 4

Yeah, and it's seeming more likely that you could start to say the same thing about React: it's not a great solution for building websites, but everybody uses it for that.

01:01:39 - Theo Browne

Here's the fun thing that's changing, though. React gets so much better with server components. Compared to a specialized solution like Astro or Remix that's specifically focused on its own pattern, its own routing, its own loading—you can get something more optimal. In the end, React is giving you primitives that, just by switching to them, the result is a more performant app. It's not the most performant, but from these primitives you can make the most performant thing. It's just a matter of the actual building blocks we play with getting better.

01:02:14 - Speaker 4

My follow-on to that is that the React core team has done a very good job of bringing the community along with their evolution of the framework—unlike pretty much every other framework in the past where some massive architectural change was needed and they lost 90% of the audience. So we'll see if they can continue to do that. The end has not been written on server components, obviously, but if anyone can pull it off, the React team has the track record, because of incremental adoption and all those other things.

The one nitpick I have—and again, I haven't delved into server components as deeply as I should—is the use client directive and use server. That just feels like too blunt of an instrument, especially from a developer experience standpoint. Just looking at the documentation, it's like, now I've got this thing over here that can only run on the client, and it feels like there's too much going on to be really easy to maintain in a large application.

01:03:30 - Speaker 4

But I'll withhold judgment. Theo, maybe you have some more thoughts on it?

01:03:35 - Theo Browne

I don't like how it's named, and I'm not all in on the separation just yet. I don't like when my file system is prescribed to me by somebody else. I get why they're doing it—it makes the code splitting much clearer and easier. If you don't import it in a component marked use client, it won't be shipped to the user. And I think that is a very valuable distinction versus other frameworks that don't have quite as clean a split. The only other thing that comes close is Astro, but even that, you have to understand bundling and independent frameworks well enough to get what it's doing.

If it were named use interactive, I think that would make much more sense. Mentally that's how I'm thinking of it: is this a thing the user does something with? If yes, use client. If no, don't. I don't like having to separate the input component into a separate folder from the data component. But when I go back and look at the code I wrote at Twitch, we had container and component files for every single thing that we rendered.

01:04:36 - Theo Browne

The container would do some GraphQL data fetch and wrap the component. The component would actually render. It feels kind of like that, but we get to choose where the boundaries are, as long as the boundary of "interactive" exists somewhere.

01:04:52 - Speaker 4

Yeah, and given that we're forced to have a compile step—I know we touched on that at the beginning of the stream—it seems like there could be something where we have a file with a component where part of it is server and part of it is interactive. I like that term. The compiler figures it out, and you have some convention for how to do that. Again, that's not a solution—it's wishful thinking—but we have a compiler. Maybe we should figure out how to use it.

01:05:19 - Scott Steinlage

I don't know.

01:05:20 - Anthony Campolo

Anyway, Dev's had his hand up for a while. One thing I want to say is I think having more prescribed file structures would be great for JavaScript. Having a prescribed file structure only prevents bugs, and people who don't like it insist on doing everything their own way. I think file structures are great. But Dev, go ahead.

01:05:44 - Dev Agrawal

Yeah, it's 4pm already—I won't take too much time. But Ellery brought up a great point. I think a lot of the conversation around RSCs has been purely from the perspective of content-heavy sites, because a lot of the meta-frameworks have been pushing for that market share—making it much easier and faster to develop content-heavy sites. But it's really important to understand that React is not only serving content-heavy applications. It has to serve the entire spectrum from content to interaction-heavy applications. I think Dominic Gannaway also brought up this point—I'll have to find the tweet and link it here.

So yeah, I think this is why their solution to these same problems looks very different from existing solutions like Remix and SvelteKit: they're trying to serve more than one use case, which is why their solution is inherently a little different, more low-level, and requires the full picture to understand. I think RSCs work great when you have separate pieces of interaction that have their own data flows and are kind of independent of each other. And you can do a lot of that in Astro thanks to islands, which is why Astro is the best comparison.

01:07:12 - Dev Agrawal

And I think a lot of the conversation about how RSCs are going to achieve the same things that Remix does—which we heard a lot of in the stream earlier today—is why that conversation tends to get confusing, because it's inherently a very different concept. It's supposed to serve a much larger audience than someone who's just trying to get the first byte or the first paint out as soon as possible. That's all I have.

01:07:42 - Speaker 4

Totally agree.

01:07:43 - Scott Steinlage

That's very good. Thanks so much for sharing. Real quick, guys—I just want to thank everybody for joining us today. We are still going here strong, but just want to let you know we do this every Wednesday at 12pm Pacific Standard Time. Whether you're new to this or you've been doing development for a very long time, it doesn't matter. We'd love to hear from everybody, so feel free to request to come up and we'll be happy to bring you up. Ask questions, state facts, opinions, whatever—we'd love to hear from you.

01:08:12 - Anthony Campolo

This is a great crew. Thank you everyone who showed up.

01:08:14 - Scott Steinlage

Thank you so much. If you've gotten value from anybody that's up here right now or was earlier, please feel free to click on them and follow them—I guarantee you'll get value from them in other places as well. And of course JavaScript Jam wouldn't mind the follow too. So thank you all so much, and let's continue.

01:08:37 - Anthony Campolo

Who else has a hot take?

01:08:39 - Jason

I would just add real quick that I have no doubt that Astro and Qwik are going to have the best time to first byte. No question about it. So if that's your metric, you should stick with one of those two.

01:08:52 - Theo Browne

Depends on what you have in it.

01:08:55 - Dan

Go ahead, Theo.

01:08:56 - Theo Browne

Depends on what you want your first

01:08:58 - Ellery

byte to have in it.

01:08:59 - Theo Browne

The fastest time to first byte is always going to be something on a CDN.

01:09:02 - Anthony Campolo

I was about to say, once

01:09:03 - Ellery

you start involving a CDN and caching, TTFB is almost a function of your geography and not the framework.

01:09:12 - Jason

Oh, that's an excellent point. Something like ElastiCache, or something cached like Edgio. Doesn't Edgio do caching?

01:09:20 - Anthony Campolo

Oh yeah, you can literally just put

01:09:22 - Theo Browne

a cache header on your response in Vercel and you're done. Programmatic invalidation is pretty hard to beat.

01:09:32 - Scott Steinlage

Awesome.

01:09:36 - Suvi

Yeah. Hey guys, can you hear me?

01:09:38 - Scott Steinlage

Yeah. How do you pronounce your first name?

01:09:40 - Suvi

Just call me Suvi.

01:09:42 - Scott Steinlage

All right.

01:09:44 - Suvi

Yeah guys, I was really enjoying the valuable insights from everyone, but I want to highlight that for most of the websites we make in Astro or React server components, I think the benefit lies if you're making static content. Because if you do an RSC and add a client component that is heavily interactive, we're going to load a lot of JavaScript, and that will create a problem of hydration—even in Astro. If you create an island and opt in to JavaScript, it will become heavier again. I think we have one bigger problem I want to address, and that's hydration. The minute you're making interactive websites, hydration is going to be a problem. It doesn't matter if you use React server components, Astro, or SvelteKit. So I think we should address the concept brought by Qwik, which is resumability. I've been following it for quite a while and it's really mind-blowing. I want to ask what you guys think about it.

01:10:46 - Anthony Campolo

You just summarized a tweet I wrote a while ago in such a great way. I said Astro's for sites, Qwik's for apps—as a reference to the "Svelte is for sites, React is for apps" thing. What you said is exactly what I was trying to get across with that.

01:11:02 - Suvi

Yeah. I've been following Misko a lot, and

01:11:12 - Anthony Campolo

he's our guest next week.

01:11:16 - Suvi

Yeah, I would love to ask him this question. I think I already agree, but I want to know other people's views on it, because I think resumability is one of the best concepts I've ever read about and people are not talking about it enough. I'm also a pretty big fan of signals, but I think over time signals will be default in every framework. Implementing resumability is one hell of a task though—you literally have to build a framework from scratch to make resumability work. It's not easy to implement in frameworks that have been around for the last five years.

01:11:58 - Dan

I think resumability is a great concept, but the idea that hydration is fundamentally a problem is not true. It's good marketing to criticize hydration because everyone's using it and a lot of apps are very slow. But hydration is not fundamentally a problem—it's contextually a problem. If you're loading a lot of JavaScript, things might get slow, but that doesn't mean it needs to be split into a thousand pieces. It's a cool technique and it will make apps faster, but it doesn't mean that every other hydration approach is wrong.

01:12:35 - Anthony Campolo

I'd be curious, Ellery, because I know you have lots of thoughts on hydration. Is hydration fundamentally a problem? And we lost you there for a second, Dan.

01:12:44 - Dan

No, I'm back.

01:12:45 - Anthony Campolo

We got most of it. You're back. Yeah.

01:12:47 - Dan

Okay. Yeah, but like SolidStart and SvelteKit—SvelteKit is fast. You can't come up to me and say SvelteKit is slow, you have to use Qwik, unless you actually have a slow SvelteKit site that you can't refactor.

01:13:06 - Jason

It's definitely fast. I agree with Dan 100%. Somebody made a comment characterizing it as dwelling—if you're dwelling in the app for a long period of time, you want fast client-side transitions, and that's going to be the benefit of hydration. And also I want to agree with you on SvelteKit. I used that for a reporting tool, which is the ultimate client-side app, and it was the slickest thing I've ever seen or touched in my entire life. It had DuckDB—which is like SQLite but for analytics—as the cache layer after pulling a bunch of data down, and the actual dashboard itself was a Svelte app. It was radical. It was revolutionary. It was just amazing.

01:14:07 - Ellery

Yeah, I'll chime in here. I am not a big fan of hydration. I also think the VDOM is overhead. I really like what Qwik is doing. One of the things I really dislike about frameworks like Next and Nuxt is that TTI is always going to be slow. Forget TBT and TTFB. The moment I see a paint, I want to be able to interact with the site without having to go load chunks, wait for the app to spin up, and hydrate things that were already painted as part of SSR but aren't really interactive yet. It leads to a really poor user experience. So I'm on board for any framework that can solve that in a way that isn't onerous to develop on. I will jump ship immediately.

01:14:56 - Suvi

I just want to add to Ellery's statement. I was on a podcast with Dan Shappir—he's like a performance master. He said that Core Web Vitals doesn't even include TTI yet. So the minute you include TTI in it, all the websites will fall really badly. That's one reason Google is not making that change now—FID only checks whether you can click on a button, not whether the button actually does what it's supposed to do. TTI is about when you click a button and it literally does something functional. The minute TTI comes into Core Web Vitals, many websites that currently have a great score are going to drop really badly.

01:15:42 - Anthony Campolo

Yeah, Core Web Vitals leaves all sorts of important things out.

01:15:45 - Scott Steinlage

Great call-out. If you want to check that out, you can go to JavaScript Jam—that was last week with Dan Shappir.

01:15:57 - Dev Agrawal

Yeah. And I wanted to respond to that earlier point about why signals matter so much. If you're someone interested in resumability and eliminating hydration as much as possible, signals is still a very interesting thing you should look at. Because what signals enable is that once you have the reactive graph of how data updates change the UI, one possibility is that you only ship that reactive graph to the client instead of entire components. I believe Qwik is working on something like this. Dominic Gannaway is also working on something like this—I put one of his tweets about it in the replies.

Basically think of it like this: if you have a component that has five divs and you're using a signal to show some text inside one of those divs, the bundle you send to the client won't have any of those divs at all. The only thing it will have is some code that finds the div it needs to update in the DOM and only updates the text inside it.

01:17:12 - Dev Agrawal

You don't have to ship your components at all. The only thing you have to ship is the specific DOM update logic and what signals or reactive values that DOM node is listening to. That's it. And again, if you're interested in reducing bundle size and eliminating hydration, I think signals is still a very exciting thing to look toward.

01:17:41 - Suvi

I totally agree, Dev. What I mean is that signals should always be there—there's no point in re-rendering an entire component just to update a heading. That should always be the case. And somehow we're seeing it a lot now, thanks to Ryan highlighting this problem. I feel like every framework has it in some way except React. But what I read is that React is working on something called React Forget, a React compiler, and after that you literally won't have to specify ten dependencies and manage all that yourself. So what I mean is that signals will be default in a year or two in every framework. I think it will be there. I in no way want to minimize the capabilities of signals. I just feel like they should be default in every framework.

01:18:36 - Dev Agrawal

Clearly you're in heavy disagreement with the React core team there—like most of us actually.

01:18:44 - Dan

It's been super cool to see the React core team really double down on their rendering approach with all the signal stuff going on. Props to them for standing their ground, I guess—at the expense of... well, there's no real expense. You can just go use another framework.

01:19:02 - Anthony Campolo

Well, standing your ground is much easier than rewriting the entire framework.

01:19:06 - Dan

Yeah, I mean Preact didn't rewrite the entire framework, but Preact is a lot simpler than React.

01:19:15 - Suvi

I recently saw this video from Jack Harrington. He said that somebody made a library called Jotai Signals, so you can actually use Jotai atoms with signals. You can literally use—

01:19:28 - Anthony Campolo

Oh my God.

01:19:30 - Suvi

Yeah. I think there are already five libraries out there using signals in React. But I think it doesn't work with React concurrent mode, so you have to be aware of that.

01:19:40 - Anthony Campolo

This reminds me of when people were trying to write Tailwind in JS or something—they just started shoving everything into everything and it became completely ridiculous. I think if signals aren't actually in your framework, trying to hack in a state management thing that's doing something equivalent is probably a bad idea.

01:20:03 - Jason

Yeah, signals are like a diet version of RxJS. There's actually redux-observable, which uses RxJS. So it combines the time-travel debugging and developer tooling of Redux with the observable framework of RxJS. But its version compatibility is old—Zach's not keeping it up to date—so it's not compatible with the latest Immer and RTK and RTK Query and stuff like that. Somebody's got to jump in there and beef it up. Maybe I'll try that.

01:20:48 - Dev Agrawal

I'm not sure you want to open that signals-versus-RxJS can of worms.

01:20:54 - Dan

Hey, in Angular you can use them together. I'm super impressed that Angular managed to convince a bunch of people to use RxJS. I've been teaching signals for a year or two and it's hard enough getting people to use RxJS and actually use it in their apps. Props to you, Angular community.

01:21:15 - Anthony Campolo

I don't think they convinced anyone. I think they just did it, and then people were like, I guess this is how we write Angular.

01:21:22 - Jason

Yeah, well, it's not exactly how they write Angular. There are two ways to write Angular. One is Zone.js, which has nothing to do with that. And the other is observables, which is a fine-grained update—basically signals. It's promises-plus-plus.

01:21:42 - Dan

I thought Zone.js was used behind the scenes as the change-detection algorithm, whether or not you use streams.

01:21:47 - Jason

No, no, no.

01:21:50 - Dev Agrawal

I mean, technically Zone.js is used behind the scenes—you don't interact directly with any Zone.js APIs. All you do is change a variable and the framework automatically detects that change and renders your UI. It's Zone.js doing it most of the time. You know that Zone.js is doing it, but you're not importing a function from Zone.js and calling it directly.

01:22:16 - Jason

Yeah, I'm not an Angular expert here, but basically there's a way you have to feed the observable. It's sort of like a fetcher, where the way you feed data in determines how it's rendered. If you route the data through without, the Zone will update. If you do it with observables, then the observable will update. So it's bifurcated. You can ask anybody who knows Angular—that's how it works.

01:22:50 - Dan

Okay.

01:22:51 - Jason

It's either-or, it's not both. And so signals are kind of a way to get straight to it. You can skip the Zone—which is bad UX, or it might be okay DX, but it's bad UX—and just go straight to observables. But on the happy path, starting out with signals, which are like I said the lighter version of RxJS, it's easier to start.

01:23:23 - Suvi

I read somewhere that people say they use RxJS in Angular because they have to, like they don't have any choice. And half the time that's not true.

01:23:34 - Jason

It's not. Yes, it's not true.

01:23:36 - Suvi

What I mean is, even before signals, people had a choice. But some things are natively RxJS—if you're making HTTP calls, they are streams by default, and if you want to modify them, you have to use pipe operators. You should know about them.

01:23:49 - Henri Helvetica

Right.

01:23:52 - Jason

Yeah, it's a good methodology. You don't have to use RxJS with Angular.

01:24:02 - Dev Agrawal

Yeah, and I wouldn't necessarily take either extreme position. To say that RxJS is the only way to do it is a little unfair, but also to say it's an either-or where you can use whatever you

01:24:18 - Anthony Campolo

want—it's kind of like Redux in React, right? You didn't need it, but so many people used it that you kind of thought it came along with the framework.

01:24:27 - Dev Agrawal

Yeah, but the much bigger problem was the two-way data binding that makes things kind of unexpected. It makes it really hard to track what's being changed and when. That's mostly why a lot of people skip Zone.js and go to RxJS—they get that one-way data binding, which is similar to what we have in React but with a very different API. If you want more maintainable applications where you can clearly see what the data flow looks like, you would pretty much have to use RxJS, because if you just rely on Angular's built-in change detection, it's going to get unmaintainable and messy—which it did for a lot of people. That's the entire reason we have signals: Angular's built-in change detection is terrible for any sort of scalability.

01:25:31 - Speaker 4

Awesome.

01:25:31 - Anthony Campolo

We managed to sneak in an Angular discussion somehow. Scott, you want to close this out?

01:25:39 - Scott Steinlage

Absolutely. Thank you all so much for joining us today. As I said before, we do this every Wednesday at 12pm Pacific Standard Time. Thank you so much for joining us—this was a great conversation with a great panel of folks. I really appreciate everybody who contributed, and also we really appreciate you listening in the audience. Next time, if you feel like coming up to say something, do it. Just request to come on up—we'd love to hear from you. Whether you're a beginner or you've been doing this for a long time, it doesn't matter. We want to hear from you. It drives so much more value through everything we do. And if you did get value from somebody that was up here, please feel free to click on their profile and follow them.

01:26:33 - Scott Steinlage

You will get value from them in other places, I promise. And not just that—give JavaScript Jam a follow too, so when we go live every Wednesday, you'll see us pop up in your Twitter feed.

01:26:46 - Anthony Campolo

And next week we've got Misko talking about Qwik.

01:26:49 - Scott Steinlage

Hey, and he did join us last week. So if you want to check that out, I pinned it in the comments—you can listen to last week's with Dan Shappir, and Misko joined there too. Great conversation. Every week has been really good these last several. So I'm just really excited for the future and moving forward. We've got some really, really cool things coming up with some events that we're collaborating on. I'm so excited, and I'm sure we'll see several of y'all at those events. We'll be releasing names and details soon—just hold on to your seats. It's going to be a fun ride for these next several months. Anthony and I, JavaScript Jam, Edgio—we're doing these events together. All right, thank you all so much. Greatly appreciate it, and we'll see you in the next one. And by the way, if you're not on the newsletter yet,

01:27:47 - Scott Steinlage

you need to be. You're missing out. JavaScriptJam.com—go there, subscribe. All right, y'all. Love ya. We'll see you next time. Peace.