React Rally with Tejas Kumar and Mark Erikson

Episode Description

JavaScript Jam hosts React Rally speakers Mark Erikson and Tejas Kumar to discuss DevRel, React rendering, server components, and the death of Jamstack.

Episode Summary

This JavaScript Jam live episode features React Rally speakers Mark Erikson and Tejas Kumar alongside hosts Anthony Campolo, Scott Steinlage, and Ishan Anand. The conversation opens with a discussion of what developer relations means, with Mark reflecting on how his years of Redux community support constituted DevRel without him realizing it, and Tejas emphasizing that DevRel is fundamentally about building genuine relationships with developers. Both speakers preview their upcoming React Rally talks — Tejas on why developers should use frameworks rather than building everything from scratch, and Mark on his popular guide to React rendering behavior, where he highlights common misconceptions like the assumption that child components only re-render when props change. The discussion shifts to React server components, where both speakers express cautious optimism about the technology but concern about the rollout, citing poor documentation, confusion around canary builds, and the lack of a clear migration path for existing apps. The group debates whether React is having an "Angular 2 moment," with multiple participants arguing that React's massive adoption insulates it from that fate despite the growing complexity. The episode closes with a brief exploration of whether the Jamstack is dead following the shutdown of Jamstack community infrastructure, with Anthony framing the debate as whether the approach failed or simply became so ubiquitous it no longer needs a name.

Chapters

00:00:00 - Introductions and Travel Woes

The episode kicks off with the JavaScript Jam crew gathering for their weekly Wednesday live show, though not without some drama — co-host Anthony Campolo is broadcasting from Denver Airport after a brutal travel delay involving hours on the tarmac, a plane switch, and an overnight hotel stay. The hosts banter while getting everyone connected, including some technical difficulties getting Mark Erikson into the Twitter Space.

Scott Steinlage welcomes listeners and sets the stage for the episode, explaining that JavaScript Jam is an open-mic format show welcoming developers of all experience levels. He introduces the day's focus on React Rally, the returning community conference, and teases the guests and Anthony's notably lengthy newsletter. The hosts then introduce themselves, with Anthony and Ishan representing Edgio and setting up the guest introductions.

00:04:51 - What Does DevRel Mean?

Mark Erikson and Tejas Kumar introduce themselves — Mark as a senior front-end engineer at Replay building a time-traveling debugger, and Tejas as a developer advocate running a consultancy called G.dev. Anthony opens the conversation by asking both guests what DevRel means to them, leading Mark to share an amusing story about being surprised when someone pointed out he'd essentially been doing DevRel for Redux for years without labeling it as such.

Tejas builds on Mark's answer by framing DevRel as fundamentally about building relationships with developers, noting that open source maintenance is inherently relational work. He acknowledges that some view DevRel as a grift or hype machine, sharing a candid story about receiving that feedback directly. Ishan steers the conversation toward where DevRel sits organizationally, and Tejas outlines different models — under sales, marketing, or product — arguing that the best but rarest setup is when DevRel is its own vertical with other functions reporting into it.

00:15:14 - React Rally and Conference Culture

The conversation pivots to React Rally itself, with Scott providing an overview of the conference and a special 50% discount code for listeners. Mark reflects warmly on attending React Rally multiple times before the pandemic, praising its intentional community-building approach, including extended lunch breaks with spending cash that encouraged attendees to go out in groups and build real connections through hallway conversations.

Tejas shares his excitement about attending React Rally for the first time, noting the reputation for a playful and whimsical vibe. He mentions his plans to connect with what he affectionately calls "the traveling circus" — the community of developers who keep running into each other at conferences worldwide. Ishan reinforces the value of the hallway track for career building and relationship development, setting up the transition to discussing the speakers' upcoming talks.

00:19:43 - Tejas on Why You Need a Framework

Tejas previews his React Rally talk about why every React application should start with a framework like Next.js or Remix rather than bootstrapping from scratch. He explains that while the React team's official guidance now recommends frameworks, many developers — especially newcomers — want to understand the deeper reasons behind that recommendation rather than just following instructions. His talk aims to satisfy that curiosity by building crude implementations that reveal what frameworks handle behind the scenes.

The talk will cover how frameworks manage server rendering, file-system-based routing, and data fetching, demonstrating through live code examples why rolling your own solutions leads to missed corner cases and wasted time. Tejas draws a parallel to the "don't roll your own crypto" principle and notes he'll explain conventions like why Next.js pages must be default exports. He clarifies that he won't be comparing frameworks against each other, preferring to avoid the vitriol that often accompanies such comparisons on social media.

00:24:35 - Mark on React Rendering Behavior

Mark previews his talk, which is a condensed version of his widely-read blog post "A Mostly Complete Guide to React Rendering Behavior," now approaching 12,000 words. He traces the origin to his years of answering community questions and noticing persistent confusion about fundamental concepts — what rendering actually means, how React applies changes to the DOM, and why immutable updates matter. He highlights the most common misconception: developers assuming child components only re-render when their props change, when in fact React's default behavior cascades renders through the entire component tree.

The discussion expands into the state of React debugging tools. Mark reveals that the React DevTools have received minimal investment since Brian Vaughn left the React core team to join Replay, with Meta even laying off someone who had been working on them. He explains how Replay has been building React-specific integrations into their time-traveling debugger, including component tree inspection at different points in time and proof-of-concept features for tracing click events to handler code. He also notes the conspicuous absence of any official debugging tools for React Server Components.

00:34:57 - The React Server Components Debate

Ishan asks both speakers where they stand on server components and what the adoption curve will look like. Tejas predicts a slower uptake than hooks because server components require re-architecting applications rather than making incremental component-level changes, suggesting adoption will come primarily through new projects rather than migrations. Mark shares a similar view, expressing positivity about the concept but sharp criticism of the rollout, citing missing documentation on the core React site and community frustration over the framework recommendation shift.

The conversation deepens as Mark describes specific pain points for library maintainers, including bugs caused by canary build inconsistencies and the confusion around client components in the app router. An audience member, Jason, pushes back on the "Angular 2 moment" comparison, arguing that React has maintained strong backwards compatibility unlike Angular's ground-up rewrite. Tejas reinforces this point by noting React's massive enterprise adoption — from Netflix to Apple to GitHub — puts it in a position more comparable to JavaScript itself, where people complain but continue using it daily.

00:49:01 - Enterprise Concerns and Learning Paths

Jason expands on the enterprise perspective, noting that server components make excellent sense for content-heavy sites but create infrastructure challenges for teams building internal single-page applications that currently deploy to CDNs without server rendering capabilities. Audience regular Bro Nifty chimes in about composable enterprise architecture and shares his perspective that beginners might be better served starting with Svelte before working their way to React and more complex frameworks.

Mark pivots to discussing the React learning path, expressing concern that despite the excellent new React documentation at react.dev, there's a missing step between completing the tutorial and starting a real project. He notes the awkward situation where the docs recommend Next.js, but a new Next project defaults to server components, which introduce entirely different constraints than what the tutorial teaches. This leads to a broader discussion about open source documentation incentives and whether the quality of documentation in the ecosystem was partly a zero-interest-rate phenomenon driven by VC-funded companies.

01:05:49 - Open Source Documentation and Incentives

Eric raises the question of who bears responsibility for documentation when the creators of a framework like React don't necessarily owe the community anything. Mark draws an analogy to fantasy authors with unfinished book series, exploring the implied obligation that comes with publishing a framework and actively encouraging adoption. The conversation touches on the tension between Meta's internal use of React and the external community's needs, noting that Meta never shared many of its internal tools like forms libraries.

Ishan proposes a provocative take — that high-quality open source documentation may have been partly a zero-interest-rate phenomenon, funded by VC-backed companies with financial incentives to build developer ecosystems. Mark acknowledges the point before signing off, and the group reflects on how the current macroeconomic environment with reduced funding could affect the broader ecosystem's ability to produce the kind of thorough documentation and community support that developers have come to expect.

01:16:03 - Is Jamstack Dead?

The episode's final segment tackles the week's big story from Anthony's newsletter: the apparent death of Jamstack as a brand, with the creators moving on, the Jamstack conference ending, and the community Discord shutting down. Anthony frames the debate around two opposing viewpoints — either Jamstack was never a valid approach, or the term has become unnecessary because the principles are now universally adopted. The group leans toward the latter interpretation.

Bro Nifty suggests a rebranding to "CDN and bring your own APIs," while Ishan reflects on a talk he gave two years earlier about Jamstack's identity crisis, comparing the term's trajectory to "HTML5" or "flat screen TV" — concepts that won the market so thoroughly they no longer needed distinct branding. The hosts wrap up by promoting next week's guests, David Khourshid and Shirley Wu, and reminding listeners about the React Rally discount codes and the JavaScript Jam newsletter at javascriptjam.com.

Transcript

00:00:01 - Anthony Campolo

Hello, hello. Coming at you live from Denver Airport.

00:00:11 - Mark Erikson

Hello, hello.

00:00:14 - Anthony Campolo

What's up, Ishan?

00:00:16 - Scott Steinlage

Hey, hey, hey, hey.

00:00:18 - Ishan Anand

Welcome, everyone, to JavaScript Jam. I don't know if I'm at the beginning. There was a...

00:00:23 - Scott Steinlage

No, you didn't. We're about to go with the intro right now.

00:00:25 - Mark Erikson

Okay.

00:00:26 - Scott Steinlage

Yeah, buddy.

00:00:28 - Ishan Anand

But where in the world is Anthony San Diego right now?

00:00:36 - Scott Steinlage

Where in the world is Anthony San Diego?

00:00:40 - Ishan Anand

Hey, I'm glad you guys hit that joke.

00:00:41 - Anthony Campolo

You never know.

00:00:42 - Ishan Anand

But so, for those who don't know, Anthony almost didn't make it to host today because of some travel difficulties. I think you're...

00:00:53 - Scott Steinlage

How...

00:00:54 - Ishan Anand

How many hours were you on the tarmac?

00:00:57 - Anthony Campolo

Well, I was on the tarmac for, I think, about four hours, and then we had to switch planes, so it ended up being about a six- or seven-hour delayed flight.

00:01:06 - Mark Erikson

Oh my gosh, that's brutal.

00:01:10 - Anthony Campolo

And because we had a connection, we were gonna miss our connection, so we had to get a voucher, then go to a hotel to stay overnight, and then get a shuttle back so we could finish our flight today.

00:01:23 - Scott Steinlage

Oh, man, that's like the minimum they could do. Honestly, I feel like they should just be like, here's some free plane tickets for later.

00:01:29 - Anthony Campolo

Yeah, they're buying my lunch too, so that's nice. By the way, it looks like Mark might be struggling. Did anyone brief him on how to do a Space?

00:01:41 - Scott Steinlage

I did tell him he should get on mobile via the email to him, so I sent it to everybody. But yeah, all right, yeah.

00:01:55 - Ishan Anand

Well, you can go ahead, do

00:01:56 - Anthony Campolo

the intro and he'll make it up when he can.

00:01:59 - Ishan Anand

Yeah, why don't you take it away?

00:02:01 - Scott Steinlage

Sure, I'll take it away. Welcome, y'all, to JavaScript Jam Live. We do this every Wednesday at 12:00 p.m. Pacific Standard Time. If you're here, you know the time. All right, so thank you so much for joining us. We got several people here that are added as speakers. There you go. What's up, Tejas? What's going on, bro? Just giving an intro here. Thank you so much for joining us. Whether you're a beginner or whether you're an advanced developer, it doesn't matter. We want to hear from everybody, okay? Or whether you're just thinking about getting into things. Okay. You're not even there yet. Doesn't matter. We want to hear from everybody. Why? Because that brings more value to everybody participating, listening here in the room, and listening to the recording in the future. Typically, we have some really great conversations that come from people just coming up and doing that. So if you have any questions, comments, concerns, facts, opinions, statements, it doesn't matter. We want to hear from you. But today we have a very special, exciting thing we're gonna be talking about: React Rally. Yeah, it's back. We all... yeah. And we got a couple speakers there from React Rally.

00:03:10 - Scott Steinlage

We got Tejas Kumar and Mark Erikson gonna be joining us today to chit-chat about some fun stuff. And we got some spicy takes from Anthony. If you didn't get the newsletter, you need to be on it because it was spicy.

00:03:29 - Anthony Campolo

This is my magnum opus, the longest one I've ever written. Quite a lot.

00:03:36 - Scott Steinlage

It was good, though. Y'all go to JavaScriptJam.com, sign up for the newsletter so you don't miss out, and you know what we're going to be talking about typically on these Wednesdays. All right. And we got Mark in. Awesome.

00:03:49 - Mark Erikson

Please tell me I'm here.

00:03:52 - Scott Steinlage

You are here. I hear you.

00:03:53 - Mark Erikson

Okay, cool.

00:03:55 - Scott Steinlage

All right.

00:03:56 - Anthony Campolo

So sweet, Simpson-y voice.

00:03:57 - Scott Steinlage

Yes, absolutely. So I'm gonna go ahead and just introduce myself, and we'll go around the table here. So my name is Scott Steinlage. I'm a technical community manager here at Edgio and co-host of this here podcast, JavaScript Jam, with Anthony and Ishan.

00:04:14 - Mark Erikson

Yo yo.

00:04:14 - Anthony Campolo

I am a developer advocate at Edgio. Super happy to have our speakers here. Big fans, both of them.

00:04:22 - Ishan Anand

Yeah, same here. I'm Ishan, VP of product for the applications platform at Edgio. That's security, CDN, and, you know, Jamstack-type hosting, if that word is still around.

00:04:38 - Anthony Campolo

You're not allowed to use it anymore.

00:04:40 - Ishan Anand

Yeah, we can talk about that maybe at some point today, but really excited to have the React Rally speakers here. Hi, everyone.

00:04:51 - Scott Steinlage

Awesome. Speakers, who would like to go first? Either one, doesn't matter.

00:04:58 - Ishan Anand

Sure.

00:04:58 - Mark Erikson

Hi, I'm Mark Erikson. I am a senior front-end engineer at Replay, where we're building a time-traveling debugger for JavaScript applications. In my free time, I spend a lot of time answering questions about React and Redux.

00:05:16 - Tejas Kumar

Hi, everyone. I'm Tejas Kumar and I am a developer advocate with a small consultancy called G.dev, and I have the privilege of working with a number of different dev-tools, developer-oriented companies, helping out with DevRel if and where we can, and I'm thankful to be able to even say that. Mark and I have worked together on some Replay things in the past, so I'm really excited to be here and share in this conversation with everyone.

00:05:47 - Scott Steinlage

Super exciting. Thank you so much for introducing yourselves, y'all. Let's give them a round of applause. Thank you so much for being here with us today. Yeah, give them some love. All right, cool. Anthony, did you want to kick it off?

00:06:03 - Anthony Campolo

I mean, I just want to first say, I want to take a second and blow some smoke up both your butts, because I think you two are both just really great community members. I've always seen you both out there just doing DevRel, right? I feel like... so I'd be kind of curious, what does DevRel mean to both of you?

00:06:23 - Tejas Kumar

Mark, do you want to take this one first?

00:06:27 - Mark Erikson

I can try, actually. It's really ironic because I started working at Replay in March of last year, and I'd only been doing the job-search thing for a couple months before that. And I'd said publicly I was looking for a new job, and I was very specific that I was looking for a full-time, 100% developer role. And someone actually contacted me and said, you know, we're looking for a DevRel position. Are you interested? I remember mentioning this on the side to some folks. I'm like, that is clearly not what I'm looking for. Why would anyone be suggesting that to me? And they messaged back and said, Mark, you've basically been doing DevRel for Redux for years. I'm like, oh, okay, that's an...

00:07:18 - Anthony Campolo

interesting, shocking revelation to hear. I've known other people who've had a similar moment.

00:07:27 - Mark Erikson

So, I mean, in that sense, I don't necessarily have a lot of feedback on the term DevRel, because it's not a term that I've normally applied to myself, even if that is kind of how you could actually classify what I've been doing.

00:07:45 - Anthony Campolo

I guess my question would be then, what is it that you do, do you think, that makes people see you as DevRel if you don't even see yourself that way?

00:07:53 - Mark Erikson

So, I mean, I've done a bunch of stuff, but I've thought of it more in terms of being a maintainer and trying to support the community, which, I mean, I guess is actually maybe a decent starting definition of DevRel. I mean, there's the actual maintainer work of working on the library, fixing bugs, adding new features, improving tests. There's writing lots and lots of documentation. But then it's also about being very proactive and watching community discussions, seeing what kinds of questions people are asking, intentionally going to the places where people are asking questions, Reddit, Twitter, Stack Overflow, issues, Discord, actively looking for and responding to those questions, and then getting a sense of what kind of problems people are running into and rolling that back into the library and trying to come up with APIs and documentation and whatnot that actually address those questions so that things get handled ahead of time.

00:09:07 - Jason

Awesome.

00:09:08 - Anthony Campolo

And then Tejas.

00:09:10 - Tejas Kumar

Yeah, I mean, it's funny because, Mark, what you mentioned you were doing on Redux was basically DevRel, right? Even I see that kind of, as you mentioned it, because that's, to me, what DevRel is. It's developer relations. And being an open source maintainer is probably a very relational thing because you're dealing with people most of the time. You're dealing with issues that random people will open and say, hey, I'm having trouble with this, or hey, this doesn't work, or hey, this API confuses me. And then you've got to literally relationally engage and talk through, okay, do you have a reproduction? Do you have a replay? You have to work with people. And it's true not just for maintainers, but in open source in general. So I feel like open source itself is very DevRel-heavy, and I think a lot of us just don't see it that way. And so to me, it's that, right? It's developer relations. It's having relationships with developers, and ideally good ones. If you throw capitalism into the mix, then it becomes having these relationships for the purpose of profit and increasing shareholder worth. Which, sure, that's a nuance, but fundamentally, I think at a baseline foundational level, it's literally just having a relationship with developers of sorts.

00:10:32 - Tejas Kumar

And ideally that relationship is high quality, and then marketing and add-ons and all these things come on top of that. But by and large, it's just relationship. So I guess, to some degree, even this Twitter Space is a DevRel thing. I'm talking to all of you developers, and what we're doing together is we're creating a relationship that is DevRel. Specifically, if I have a relationship with one of the listeners here whose name is Dev, that's like DevRel squared. That's like Dev DevRel. You know what I'm saying?

00:11:04 - Anthony Campolo

That's funny. Yeah, no, I love that. And I love that both your answers were fairly different. But the great thing about DevRel is that it is kind of what you make it. I've known so many people who do it so differently and prioritize different things, and there tends to be kind of overlapping Venn diagrams of concerns that people have. They land somewhere differently. But yeah, go ahead, Tejas.

00:11:30 - Tejas Kumar

Yeah, I just wanted to add, you know, to some people DevRel is considered a grift, and I can kind of see how they would get there. And unfortunately this is a consequence of the age of having such wide reach available to us on platforms like Twitter and LinkedIn and so on. I was talking to a very prominent member of the web-dev ecosystem and I said, hey, can I get some feedback? I'm curious what you think of me. And he was like, yeah, you give me grifter vibes. And I was like, okay, tell me more. And there seems to be this conception that folks involved in DevRel are kind of just hype machines to make something look cool and sexy. And I don't think that's what DevRel is, because it's kind of like having this uncle who always comes to you with, like, you should invest in this new thing. You should invest in giving you investment advice because it's sexy, right? That's, I think, not necessarily what DevRel is. It's not saying, hey, go invest here or invest there. It's literally just relationships and high-quality relationships.

00:12:36 - Ishan Anand

I think it may also be a function of, you know, when it's an official position within an organization, where it sits in the org and what KPIs it's held to. It could be that that person may be held to a certain KPI or something like that. Where have you guys seen DevRel report to in the organization?

00:13:06 - Mark Erikson

My previous job was for a large bureaucratic corporation, so there was no DevRel involved whatsoever there. And then Replay, or, you know, pretty small startups, there's not even much of an org per se.

00:13:23 - Tejas Kumar

[unclear], but I've seen DevRel come under multiple verticals or business areas. I've seen DevRel be a function of sales, which I think is a phenomenal mistake, because hire a sales team, because what you're doing then is you're creating these almost, frankly, manipulative relationships. It's like, okay, I'll build a relationship with you so I can sell you something, okay? I'll take you on a date so I can take you home the same night. You know, this kind of thing. It feels very shady to me. But I've seen DevRel do that, as in be under sales, which I think is okay, right, personally. I've seen DevRel come under the marketing vertical, which, fair, some see it as technical marketing. And I've also seen DevRel come under product, which I think is the case for open source projects.

00:14:24 - Ishan Anand

Right.

00:14:24 - Tejas Kumar

If we consider an open source library a product, then DevRel would kind of be a function of the other maintainer duties, like Mark mentioned, on these products. One place I've seen DevRel really shine is where it's not under a specific vertical for business, but it is a vertical itself, such that marketing, sales, graphic design, all report up to DevRel, where the most important thing is the relationship to developers who are also customers. And then everything kind of is funneled to it and ultimately through it to customers. And I've seen that actually go really well in the past. It's just very rare. You'll almost never see this in the wild. And I keep asking myself why.

00:15:14 - Anthony Campolo

Awesome. So do we want to start getting into the... well, actually we should talk about React Rally. What is React Rally?

00:15:20 - Scott Steinlage

Yeah, I was about to say. Yeah, yeah. So real quick, I mean, first of all, I would say React Rally is a community conference about React and topics interesting to React developers, focusing on a friendly, kind of welcoming atmosphere like a lot of conferences, right? But engaging talks from new and established speakers, and then plenty of hallway-track stuff, time to chat with interesting folks too. And there's plenty of speakers that are going to be there that you all probably know. Obviously, speaking of Tejas and Mark, but several more, like Ben Holmes and Monica Powell and Kent C. Dodds, and just the list goes on that y'all probably know. Anyway, with that being said, I would like to also say that React Rally did put a comment in here for 50% off for the first three people to use it, so don't miss out on it. I don't think you're gonna see a discount like that anywhere else. So 50 off for the first three people if you are listening to this. And hey, if you're listening to the recording, you may get the opportunity to get in there.

00:16:33 - Scott Steinlage

I don't know, just give it a try. So anyway, with that being said, I would love to get Mark and Tejas' opinion on React Rally and what they think and what they're excited about coming up.

00:16:51 - Mark Erikson

So I'd attended React Rally I think maybe three times, like '17, '18, '19, you know, prior to the pandemic. And it's a wonderful conference, definitely one of my favorites that I'd gone to before. And I was really sad when they had to put it on pause for a couple years. You know, the atmosphere, the organization, every conference ends up having its own unique vibe, and it's a combination of how it's organized and who's there, and then some intentional factors about how it's being run. And one of the things I appreciated was, you know, they gave us a couple-hour-long lunch breaks, sent us off with a bit of cash, and it's like, yeah, go find restaurants nearby. Go out with a bunch of people. Take time to sit down and talk and get to know folks, you know, being very intentional about trying to make it more of a community hallway-track kind of feel.

00:17:54 - Ishan Anand

That's awesome.

00:17:57 - Mark Erikson

So that was definitely something I appreciated.

00:18:01 - Tejas Kumar

Yeah, I've never been to React Rally ever before. It's my first time, but exactly what Mark said. I keep hearing this from everybody, and I keep hearing that it's got the vibe that's playful and whimsical and just fun. And I've yet to experience it, but I'll report back when I do. I'm just really excited. Unfortunately, I won't be there for the entire thing, I don't think. I've got some business in Europe shortly after. But yeah, I'm excited to see how it goes. And of course, hang out with what I call, and I don't mean this disrespectfully at all, but what I call the traveling circus. And this is just people you see in different countries over and over again, friends who I absolutely adore, people like Mark and Kent and others. So yeah, it's going to be great.

00:18:53 - Ishan Anand

Yeah, that's great. You know, one of my favorite conferences I've ever attended, it was because of the hallway track. And they do exactly what you described, which is they really emphasize that. So that's great to hear. That's a real value-add. It's really where, you know, if people come on wanting to break into the industry or for their career, this is how you build relationships that will eventually become friendships, which may eventually lead to other things in your career, as well as gain insights. That's good to hear, that they're emphasizing that instead of just talks. But speaking of talks, you guys are both speakers. I'd love to hear your pitches for them. I got the description. We'll start with Tejas. Yours is, you know, why everybody needs to use a framework. Do you want to talk us through your talk?

00:19:43 - Tejas Kumar

Sure.

00:19:44 - Ishan Anand

Give a preview.

00:19:46 - Scott Steinlage

Yeah, like some sneaky bits.

00:19:49 - Tejas Kumar

Sneaky bits or a trailer.

00:19:51 - Ishan Anand

You know, in a world dominated by frameworks.

00:19:56 - Tejas Kumar

Yeah, I mean it just dives into the expectation nowadays for React applications to start with a framework, Next.js, Remix, Gatsby, something like that, when before we used to just start with React, literally. I remember npm install react and then wire up the script tag myself. The general advice, including from the people who make React, right, from people like Andrew Clark at Vercel, for example, will be like, no, no, if you're doing React, use a framework. If you have an existing app, then incrementally adopt a framework. Or if you are starting a new app, then just npm install next or npm install remix or just start there. And cool, I see that, but I feel like a lot of people coming to React are going, okay, but why? Tell me more. I'm an engineer. I'm hungry for the details. I want to understand why and how. But the how, I feel like you can kind of Google and look through GitHub and find. There's plenty of documentation for how. But I personally, and most of the people I've spoken to, are more interested in the why. Why is that? And the short answer is because frameworks handle a lot of things out of the box that, one, take a lot of time for us to handle.

00:21:11 - Tejas Kumar

But also, if we do handle them, there's a ton of corner cases that we just don't see. This is kind of why people say don't roll your own crypto. Very similar to don't roll your own framework, because you'll also probably end up implementing what frameworks do, but you'll probably do it worse. And in the time that it took you to do that, you could do a bunch of other things, including focus on your actual product, right? So we'll talk through specifically how frameworks handle things like server rendering, file-system-based routing, data fetching, etc. We'll do that by really just building a bunch of crap with, you know, not-thought-through code, because the focus is not so much syntax, but mechanism. What does it save us from? And how, in a very crude way, in a top-contour way, does it save us from this? And the goal is, I mean, it's I think 25 to 30 minutes, so we'll come away with a bare-bones understanding of that, and ideally we understand the why behind the sentiment.

00:22:14 - Ishan Anand

I like the use of live code examples. So it's not just an abstract principle, but you're going to give people a visceral feel. That's where you really know the concept, when you're like, oh yeah, I've seen people getting burned by that, right?

00:22:31 - Tejas Kumar

And also through it, we'll understand, for example, why, if you use the Next.js Pages directory, there's this convention and expectation by Next.js that your pages are default exports. Why is that? Why can't I have named exports as pages?

00:22:47 - Ishan Anand

Right.

00:22:47 - Tejas Kumar

So we look at all of this just by pulling at the strings and trying to write our own in a very crude way.

00:22:55 - Ishan Anand

Are you going to compare frameworks, by the way, or are you going to focus primarily on examples from Next?

00:23:00 - Tejas Kumar

Yeah, I don't buy very much into the comparison train, mainly because of the vitriol on this platform. There's people saying Solid's great, React's shit, or vice versa.

00:23:10 - Ishan Anand

Yeah.

00:23:10 - Tejas Kumar

And I don't know, I don't compare. I try to avoid comparisons as much as possible, and if I do end up doing some comparison, it will just be numbers and no conjecture. But no, I'm not going to compare frameworks in this talk.

00:23:23 - Eric

Okay.

00:23:25 - Ishan Anand

I think we had somebody come up. You know, we try to run a JavaScript Jam as an open mic and with audience participation as much as possible. So it looks like we had somebody come up. Did they want to ask you a question?

00:23:44 - Anthony Campolo

Try this one. Abidashukar Abdishar. Hello. Feel free to introduce yourself.

00:23:55 - Abidashukar Abdishar

I hope all of you are hearing me. I'm not quite good at public speaking. Firstly, if I introduce myself, I'm a software developer. I usually use Next.js. That's why I came.

00:24:08 - Tejas Kumar

This is based.

00:24:09 - Abidashukar Abdishar

I created a Next.js course and I'm interested in participating in this event, this Space.

00:24:18 - Abidashukar Abdishar

But currently I don't have any question.

00:24:25 - Anthony Campolo

Well, all right. Well, thanks for joining. If you want to pop in, if you do have a question at any point, welcome. Welcome to participate, for sure.

00:24:35 - Ishan Anand

Okay, Mark, do you want to tell us about your guide to React rendering behavior? Give us a summary of that one.

00:24:46 - Mark Erikson

Sure. So there's sort of a bit of backstory leading up to this one. So I started learning React myself in the summer of 2015, and as I was doing that, like you're reading blog posts and the docs, I came across the Reactiflux chat channels, which were technically originally on Slack and then moved over to Discord, where they are today. I spent the second half of 2015 initially just lurking and reading and trying to follow along with other people's questions and discussions. And the way I really got involved with Reactiflux was learning about React from people's questions, and then eventually getting to the point where I knew the answers to a lot of questions and could recite those back and help other people, even before I'd gotten around to writing my own first real React program, which didn't happen until like December that year. And so, you know, ever since then I've stayed pretty engaged, answering questions about React and Redux on Discord, Stack Overflow, Reddit, issues, wherever. And so I've always had a pretty good sense of what kinds of problems people are running into and what things are confusing them. I remember seeing all kinds of questions about the JavaScript this keyword while we were also using class components, and then eventually, when hooks came out, questions about this stopped, and instead we have fun questions about stale closures and why doesn't my state update on the next line after I call setState, and fun stuff like that.

00:26:33 - Mark Erikson

What I noticed over the years was that there was a lot of confusion about literally just how does React actually render. What does the word rendering mean? What is the process? What is the difference between my component returning some JSX and React actually applying changes to the DOM? When does React batch renders together? Why does it matter that I do immutable updates? All this information is available online, but it's often scattered in different places. And even within the old React docs, there was no single page that went through a lot of this stuff. So a couple years ago I sat down and I wrote a very extensive blog post. I think it started off at about 6,000 words, and I've extended it to close to 12,000 words at this point, called "A Mostly Complete Guide to React Rendering Behavior." That post is by far the most viewed and read and appreciated blog post that I've written. This talk is basically a very abbreviated and summarized version of that blog post that tries to go over a lot of the key concepts behind rendering and what React is actually doing inside.

00:28:06 - Ishan Anand

Great, thank you. So a couple of questions on that I think maybe we should clarify. When you're talking about React rendering, you're mostly going to be talking about client-side rendering and reconciliation, like rendering in the browser, as opposed to... I've seen talks saying a guide to React rendering patterns, and they're talking about ISG versus SSR. Are you covering that full spectrum or just...

00:28:31 - Mark Erikson

No, no, I'm not talking about anything server-side. I'm not talking about anything server components. This is strictly the client-side behavior.

00:28:43 - Ishan Anand

Okay, great. What do you think is the biggest area of misunderstanding that especially people are coming to React for and don't really understand about VDOM and the reconciliation process and rendering? Or maybe what is an example of where not understanding the rendering behavior is going to get you into trouble, like extra updates, things like that? What are good gotchas that motivate folks: if you don't understand this, you're going to paint yourself into a corner, you're going to run over this speed bump.

00:29:17 - Mark Erikson

So one of the most common misunderstandings I've seen over the years is a lot of people seem to assume that if you have a parent component that renders a child component, the child component will only re-render if the parent happens to pass down different props than last time. And that's not the case. In fact, React's default behavior is that when a parent component renders, React will then try to re-render the child, regardless of what props the parent passed down, whether they're the same or different or no props at all. It's just the parent rendered, therefore the child renders, therefore the grandchildren render, and it just recurses all the way down the component tree. In a basic standard React application, if you call setState in your top-level app component, React will actually recurse through the entire component tree and ask every single component in the tree, what do you want the UI to look like now? And it just asks everybody. Unless you actively do work to change the default behavior, a lot of people don't realize that's how React actually works out of the box.

00:30:49 - Ishan Anand

Yeah, that's a good gotcha. And then do you feel like the tools around debugging and understanding this are getting better over the years? Certainly from the beginning of React?

00:31:06 - Mark Erikson

That's a very interesting question, especially given the company that I work for. One of the things I loved about React from the beginning is that the React DevTools browser extension exists. I'd worked with a couple other frameworks like Backbone, and there were some very limited dev tools for those. But the fact that the React DevTools exist, that you can view the component tree, that you can look at props and state and hooks, and have it do the little flashing rectangles when components re-render and stuff, has always been one of the huge advantages of React for me. Interestingly, the person who wrote a lot of the current React DevTools implementation, Brian Vaughn, left the React core team a year and a half ago and joined Replay, and has been my teammate at Replay for the last year and a half. There's actually been a very limited amount of official Facebook/Meta paid work hours going into the React DevTools in the last year and a half, and I think they actually just laid off one of the people who had been doing that. So, like, in that sense, the React DevTools have not necessarily been getting better lately because they literally are not putting engineering hours into improving them.

00:32:36 - Mark Erikson

On the flip side, I said earlier at Replay we're building a time-traveling debugger for JavaScript, and because it records the whole browser, you can record anything, no matter what framework or vanilla JS it's written in. But we use React in our own product. We care about React developers as a target market. We've actually built a number of specific integrations into Replay's time-traveling debugger that let you do things with React. One is integrating that same React DevTools component tree as a piece in our time-traveling debugger so that you can see what the component looked like at different points in time in a recording. I have actually been playing around with some further proof-of-concept integrations over the last six months for things like being able to go from we know that the user clicked at a certain point in time to jumping to the line of code that handled that click event, or even playing around with trying to do some time profiling based on the recording. So in a weird way, my company is actually probably putting a little more effort into trying to build React-related debugging features than the actual React team is right now.

00:33:58 - Mark Erikson

I actually saw someone tweet just a couple of days ago that they had built a little proof-of-concept sort of standalone dev tools for React Server Components, and I haven't had a chance to go back and look at that in more detail, but Brian and I had both noted that the fact that there is no official Server Components dev-tools debugging experience seems like a pretty big oversight.

00:34:22 - Ishan Anand

Yeah, it definitely seems like a white-space area that needs to be filled, and another huge area for potential confusion on what server components are.

00:34:32 - Tejas Kumar

Yeah, but if I can chime in here a little bit about that, server components are a work in progress, so it's not like there aren't dev tools for it, it's just they're a work in progress. So it'll probably come. Everybody knows and everybody preaches and teaches that it's an incomplete thing, and by definition that means you don't have dev tools yet. This is fine. This is not a big deal.

00:34:57 - Ishan Anand

Well, maybe this is an interesting tangent. Both of you guys, where do you guys fall on server components? Good, bad? And what do you think the adoption curve is going to look like? Is it going to be slow? Is it going to be fast? Hooks were remarkably fast, at least from my vantage point. I'm curious if you think we're going to see that with server components or not.

00:35:21 - Tejas Kumar

Personally, I don't think we're going to see that with server components, but that's because it's a bigger migration. Instead of writing one component differently, where instead of a class component you reach for a function, what you're doing is re-architecting your application. You're starting from a server, and if you have a Create React App that you kind of bootstrapped with either CRA or Vite, just adding a server is not an easy task, especially not at scale. So it's not going to be an easy migration. At least, this is my... I'm really hoping I'm wrong, but for that reason I think it is a bit of a steeper adoption curve. And so personally, if you ask me, I feel it's probably more realistic that we'll see RSC be more of a normalized thing over time through new projects. But in terms of incremental migration and adoption, kind of like we did class components to hooks component by component, you just can't do that component by component because it's a bigger foundational change to the architecture of your application. So that's not to say it's bad, I just think it's a bit harder to migrate to.

00:36:34 - Tejas Kumar

But it definitely has its merits. I mean, the data-fetching story is solved, right? Suspense for data fetching is here, and it's called React Server Components. So I think there's this tremendous value, but this value will be a slow burn, is kind of the way I see it. But I'm curious about Mark and the

00:36:52 - Mark Erikson

other speaker's take. I basically have the same take, and I've actually had a number of discussions with folks on the React team over the last few months, both in person at conferences and via some chat channels. I am positive on server components as a concept. I think that they have value and they can be potentially useful. I am rather pessimistic on the way they've been rolled out and the lack of documentation and migration story. You know, I fully acknowledge everything Tejas just said, that they're a work in progress and we can't expect to have everything right away. But my own personal complaints, and the complaints that I have seen many, many people in the community express in various discussions, is that it's horribly confusing. Some of the documentation on how to use them only exists within the Next documentation site. There is nothing on the core React docs site about what they are, how to use them, how they fit in architecturally. There's nothing about how to migrate an existing single-page app to take advantage of server components. Lots and lots of people are upset that the React team just switched from recommending Create React App to saying, well, use a framework, Next, Remix.

00:38:31 - Mark Erikson

And well, I guess if you don't want to, you can use the... I guess literally with the phrase "we can't stop you" in the docs. And that has rubbed a lot of people the wrong way, and a lot of folks aren't convinced that their scenarios would benefit from server components. So I think the technology has a lot of potential. I think the rollout and the marketing and the developer education has been, frankly, pretty poorly handled. They are trying to work toward fixing that, but it's a very delayed effort.

00:39:13 - Tejas Kumar

Yeah, and I think part of that is, actually a substantial part of that is the fact that what is and was a work in progress, i.e. React Server Components, was somehow enveloped in a wider, more generally available release, that is Next.js 13 App Router. And so we have something that people are saying, yeah, Next.js 13 App Router is production-ready, but actually RSCs are not production-ready and they're still a work in progress. So there's this dissonance between, oh, okay, well then what's canary, what's not? And I think that has a lot of fuel to this fire that I think, Mark, you're alluding to. Unfortunately, that's just one of the mistakes that we learned from. But yes, I also wanted to agree

00:39:58 - Mark Erikson

with that, and one other point to bounce off of that. So the React team has been doing a lot of development work, and you now have sort of this weird versioning split in React itself where the last public release, 18.2, came out over a year ago. Next uses a special canary build if you're using the App Router, but there's no formal documentation for what any given canary version actually has. And so this has resulted in weirdness where people have sometimes run into bugs and reported them to libraries like Redux Toolkit and Apollo and said, my app broke. And number one, we find out that, okay, well, you tried to put Redux, like a React Redux provider component, in what actually turned out to be a server component in the App Router. And you can't do that because context doesn't work. Or you ran into a weird edge case with a canary build where technically you could declare a client component as async, but then it gets stuck in an infinite loop. And this has actually caused a lot of pain and frustration for us as library maintainers. And my co-maintainer Lenz Weber, who works on both Redux Toolkit and Apollo, put up a very detailed blog post a few weeks ago where he's like, we like the idea of server components, but this has caused a lot of problems for us as library maintainers in the ecosystem.

00:41:33 - Mark Erikson

Here's what we've experienced, and we have a couple of ideas for both technical and documentation improvements if anyone on the React team is interested. And we got a lot of people saying, okay, yeah, I see where you're coming from. And frankly, no one from the React team has ever really followed up on the issues we raised.

00:41:58 - Ishan Anand

Yeah, I mean, there's a lot to unpack there. And, you know, in some sense it's interesting because it's not that Meta makes revenue directly from React. And so it can be, I'm sure for those within the team, a little bit thankless. They're certainly doing it for internal usage, which I think is what makes React such an amazingly battle-tested framework, because they're really careful about rolling it out. And they've been really good about, you know, saying it's kind of damned if you do, damned if you don't. People are like, when do we get Suspense? When do we get RSC? And they give it to us in bits and pieces, and then people are like, how come it's not production-ready, right? But it's an interesting parable when I think about what happened with Angular, where Angular seemed unassailable, and then one of the things that hit them was React coming out and coming with a simpler model, but also their own migration from what is now called AngularJS, at the time v1, to v2. And I do worry that there's a narrative that's building, and this could fit into that narrative.

00:43:11 - Ishan Anand

Like, oh, with hooks, oh, you know, the controversy about Next.js being the first to release React Server Components and were they playing favorites. And it's very easy for an inaccurate narrative to build up, and this becomes yet part of the straw that breaks the camel's back where somebody's like, oh, this is just too complex, and maybe there's another thing that gets me to look at Svelte or something else. Yeah, go ahead.

00:43:35 - Mark Erikson

It's funny you say that, because there was literally a blog post and it was titled "Is React Having an Angular 2 Moment?" and a couple Twitter threads on that topic. And some React team members got pretty angry over the comparisons. And I think they're right in that, in one sense, the comparison is wrong because it's not like React is suddenly totally backwards-incompatible. It's not like it's throwing all your knowledge out the window. On the other hand, this is certainly an entirely separate set of use cases and patterns and concepts to remember that are adding a lot of complexity to our understanding of how you use React and how it fits into the existing React ecosystem. So in that respect, it is a big jump for people to make.

00:44:35 - Ishan Anand

We've got Tejas with his hand up, and then we have Jason and Bro Nifty, some regulars who are right after you. Looks like we've got some people who want to chime in. Tejas, what were you gonna say?

00:44:45 - Tejas Kumar

Yeah, first of all, I'm excited to find out how Bro Nifty sounds because I have no indication of anything about this human being. But second, about the Angular 2 moment, I feel like I would be remiss if I didn't say this, which is React has... the amount of momentum and adoption React has in the web-dev ecosystem is so tremendous. AngularJS never had that. jQuery, to some degree, still has a majority. But if you look at things like SPAs, MPAs, and more, the quote-unquote modern... I don't like that terminology. But the modern web apps, React is everywhere. I mean, Hulu, Netflix, Meta, Instagram, of course, but name any Fortune 500 company and they probably use React. Apple uses Next.js, as does GitHub, right? So this level of investment and adoption, even if it does have an Angular 2 moment, it's not going anywhere. I feel like React is at the point where, you know, we all kind of hate on JavaScript and we're like, hey, look, 2.1 plus 3.1 is equal to some weird number, or we'll do something like, hey, typeof null is an object. How weird.

00:45:58 - Tejas Kumar

Or hey, look, look, look, look at this one: typeof NaN, "not a number," is a number. Oh my God. JavaScript sucks. Like, we say things like that, but then we still use it every day and earn tremendous amounts of money from it. So it's this terrific thing that we sometimes talk nonsense about, but at the same time it's actually a giant that supports all of our livelihoods. So I think React's in a similar place where I think it's beyond the point where it can be abandoned like AngularJS was, is what I'm trying to say.

00:46:24 - Ishan Anand

So that's a fair point.

00:46:25 - Tejas Kumar

I'll.

00:46:26 - Ishan Anand

I'll push back slightly, so I'll agree and push back.

00:46:28 - Bro Nifty

I agree.

00:46:29 - Ishan Anand

They've got way more momentum. This is not like it's going to get toppled. I will say I do spend parts of my day job looking at the statistics for what frameworks are used on what sites. And, you know, like you said, jQuery still has a huge amount of staying power, and there are still actually a bunch of sites that use it that are Fortune 500, but they may not use it universally across those sites. So your point is well taken, though. But sorry, Jason, I think you were next. And then... yeah, go ahead.

00:47:03 - Scott Steinlage

I just want to say real quick, I want to thank everybody for being up here. Oh yeah, it's been an amazing conversation. Like, seriously, this has been really, really great. Man, I'm seeing some faces in here I haven't seen in a minute too, like Michael Chan. What's up, brother? Yeah, so Lawrence, yeah. Appreciate everybody coming in here and hanging out with us. Remember, this is open mic, so feel free to request to come up as these folks have, like Bro Nifty and Jason. They're some regulars here. Every Wednesday we do this, 12:00 p.m. Pacific Standard Time. And like I said, it doesn't matter if you're a beginner or advanced developer. We love to hear from everybody. So please feel free to come up here: comment, fact, solution, question, whatever, we want to hear. It definitely helps to encourage everybody here and increase the value of what we're putting out. It's a great time. So thank you so much. And don't forget to subscribe to JavaScriptJam.com, to our newsletter, because then you'll know when conversations like this are happening, and it's great. So thank you so much. Appreciate it. Jason, what's up, man?

00:48:04 - Jason

Yeah, great, great conversation. I just want to give my three cents on is this an Angular 2 moment or not. After living through that myself, it doesn't seem that way, because as far as I know you can still take the latest React and bootstrap a Create React App and create a single-page app that's completely client-side-rendered and use class-based components, as far as I know, or hooks. So whereas Angular 1 versus Angular 2 was a complete ground-up rewrite and you had to go do things a different way, a lot of adoption was missed, especially because at the time React was the up-and-comer. So it was like, well, do I rewrite my Angular app to Angular 2, or do I pick up the new cool kid on the block, which is React, and which is probably about the same amount of effort? So I don't see... I mean, other...

00:48:59 - Ishan Anand

It's a great point other than, I...

00:49:01 - Jason

I mean, I understand the passions and I understand the points that people are making about whether it's a work in progress. All that stuff is all completely valid, but React, I think, at least so far in its history, has done a fairly good job of maintaining nearly 100% backwards compatibility. And whether that's happening with your favorite framework or the new preferred method of building React apps is a different story. But you can always still build the React apps the way you want to. I don't see the parallels there. I guess the biggest thing in my mind is how much of an app is your web app versus how much is... you know, it's the web app versus website debate, right? So where with server-rendered components you're given a very clear path, if the thing you're building looks more like a website, now you have a really clear path to efficiently offload a whole bunch of computation that was being forced on your browser back to the server. So we're finally getting platform-native ways of doing that inside of React, and they're figuring out how to do that.

00:50:20 - Jason

And Next clearly has an incentive, Vercel clearly has an incentive, because they're selling server-rendering capacity. They have an incentive to make sure that you have a really good way to do that. And so if you're building an e-commerce site or a blog or anything that kind of looks or smells like that, then this gives you a really good perfect framework. Should you be having a whole bunch of client-side state and a whole bunch of client-side rendering to display your products on the internet? Maybe, probably not. Anyway, I think that's... we're given another option, especially for the Jamstack community, where we're mainly talking about here, you should probably do all your rendering on the server and ship HTML as much as possible, and then have a really seamless and transparent way, hopefully eventually, to do JavaScript when you have to on the client. So it makes a whole lot of sense for those use cases. The thing that I've kind of been struggling with, and it's great that we've got some representation from Redux here, it's like, so what about all the app people?

00:51:31 - Jason

You know, so you're thinking about inside of your enterprise environment, you're building maybe not publicly accessible apps. You're not using a rendering environment. You don't have server-rendering capability built into your deployment platform because you're not using something like Vercel. You've got to now add that capability to your deployment stack. Whereas before, if you're doing a single-page app, which is the right thing to do for the last 10 years, then you build your JavaScript and you put it on a CDN or your internal web server, and you don't have a server-rendering framework. So now you got to add that capability to your enterprise stack. So those are the sort of things that I'm dealing with, because I'm more on the enterprise app side of things than the client-facing apps. So those are the things I deal with. But yeah, that's where I'm kind of seeing both sides of the debate.

00:52:26 - Ishan Anand

Don't... yeah, maybe I wasn't clear. Like, I actually like the technical idea of React Server Components. I was just commenting on its impact on adoption, and certainly, you know, Tejas and Mark had spoken exactly to what you're talking about. You need new infrastructure capabilities, and that's going to slow down adoption. I think that makes a lot of sense.

00:52:50 - Scott Steinlage

Bro.

00:52:50 - Ishan Anand

Nifty, Mark is very eager to hear your...

00:52:55 - Bro Nifty

Yes, Ishan, thank you. Tejas, and you helped me with that, because I wasn't sure whether it was Tejas, because in my own mind I see that J with that spelling and I just think, because I studied Spanish for a while, I think that's how you pronounce that. Tay-has? But no, it is Tejas. And he did a tutorial for everyone helping us with the pronunciation. At one point I remember seeing it on the internet somewhere where he was like... so I think I've got that, okay. He's laughing, so I think I got it. All right. So yeah, my question, actually, what triggered me to come up here and just ask a question, and I think it really is better... and I really, really, really, very strongly agree with Jason, everything he was saying. And I was speaking with our friend, the module federation guy who created Module Federation, about some of this related to Vercel and stuff too. And the coupling is that in the more enterprise environments it's harder.

00:54:02 - Bro Nifty

So if you're doing enterprise stuff, you want to split things out by concern, and, like, I know that's highly charged language. But yeah, if your front end is your front end, and then you've got all these different layers and API endpoints you're hitting, and you might want to separate those things out and have composable architecture that can put it together in a custom way and how you see fit, rather than having to conform to some third-party organization or library or framework or meta-framework or host provider or whatever, I think it's simpler just to put it on a CDN and get that speed and security from it. This is unhackable, and it's obviously going to cost you a lot less money. So, yeah, you need a CDN, but do you also need those API endpoints hooked in, which really only work with Next.js if you want to do it in the API folder? You can make it work, but not without a lot of extra effort, anyways.

00:55:19 - Bro Nifty

That's as far as I want to go on with that. But yeah, what was I going to say? Yeah, what brought me up here was actually I think this is a better forum than text on the tweets, because I personally learned one tool and that got me into tech. I wasn't a tech person to begin with, and then I just did that one tool and then I worked my way out from there, and that was much simpler than trying to learn everything more generally and then work your way inward to something, I think. So somebody made a point, they were saying, you know what, I would argue that it was one of our friends, I forgot the name, but they said it was one of these frameworks like Svelte or something like that. They said just learn Svelte and do that, and then you can work your way out. And I agree with that, actually. Or React. Except I think React is much harder than Svelte because React is not a framework, it's a library. So it would be more like, say, learn Next.js.

00:56:29 - Bro Nifty

I think for a new person, Svelte will be easier than Next.js. So I would say do Svelte or something like that first, maybe, and then work your way to React. And if you want to do Angular for the enterprise patterns, like yeah, learn how Angular works. And then there's all these other ones with Qwik.dev. As I'm on Tejas' page right now... and by the way, I have to admit, I have to confess that I haven't watched Tejas' video on React Server Components. I'm really dying to do that. Like, next, it's up.

00:57:07 - Tejas Kumar

I am so offended, bro. Why you even...

00:57:10 - Bro Nifty

I'm sorry, but I know he has wonderful explanations. I watched his first video, which was on something kind of similar. It was really mind-bending, eye-opening. It was great. So that's all I had to say.

00:57:24 - Scott Steinlage

Awesome. Thank you so much for sharing that. I will allow someone to say something here shortly. I just want to come in and chime in and say, hey, look, Tejas, Mark, I don't know if you guys have a hard stop at the hour here, but we can push this out a little bit further. But I don't want you guys to feel like you have to stay or anything. You can go if you need to, obviously. But yeah, and then one thing else I want to say is if you're listening right now, thank you so much for spending some time with us. Please feel free to click on the people's faces up here that you felt like you got value from, okay? Because guess what? If you got value from them here, you're probably going to get value from them in other places. So click on them and follow them. And of course JavaScript Jam wouldn't mind a follow too as well. So Tejas, what's up, man?

00:58:10 - Tejas Kumar

Yeah, I just wanted to say I do have a hard stop. But I want to thank you all for having me, and really this discussion has been such high quality and such value to me personally, and I have no doubt to the others here. So thank you. Also, before I go, I'm going to ask that you kick Bro Nifty from the channel because he hasn't watched my... I'm just joking. But really, it's been such a good time. I appreciate all of you. Bro Nifty, I was joking. It's fine. I'm a huge fan. I'm glad I finally also know what your voice sounds like. Next step is learning your actual name. But anyway, thank you.

00:58:46 - Bro Nifty

We'll do one of these sometime.

00:58:47 - Tejas Kumar

Yeah, let's do that, right. Thank you so much once again, everyone, and I wish you a great rest of your chat.

00:58:51 - Ishan Anand

Peace.

00:58:52 - Scott Steinlage

Thanks for joining us. Greatly appreciate it. If you want to see Tejas in person, be sure to go to React Rally. Go to ReactRally.com. He's going to be speaking there, along with Mark Erikson as well. And that's why we have them up here today, actually, is for React Rally. And if you look in the jumbotron, we call it up there at the top, and you can kind of scroll left and right, you can see that they put in, and also in the comments of this, you can see they put in 50% off for the first three people who use it. So be sure to jump on that. I don't see that discount that steep anywhere else. In fact, if you stick around to the end here, I do have another discount for you, but it is not for the first three. It's actually a pretty decent discount for anybody that listens to us here on JavaScript Jam. But yeah, that's a special one. So if you don't have tickets yet to React Rally, go to ReactRally.com, use that link there, and you'll get 50 off for the first three people who use it.

00:59:47 - Scott Steinlage

So, all right, moving on. Thanks so much, Tejas. We're gonna miss you, brother. But yeah, if you're listening to this recording, we got so much more to come. So let's do it.

00:59:57 - Mark Erikson

Yeah, I actually do need to wrap it up here in a minute and get back to work myself. But I did have one more thought stemming from that last discussion. I've spent a lot of my work on Redux thinking about documentation and tutorials. I rewrote our tutorials from scratch a couple years ago to feature the newer Redux Toolkit package that we put out and teach that as the standard preferred way to write Redux code. I spent a lot of time talking with Dan and some with Rachel as they were rewriting the React documentation and trying to provide some feedback on what was going in there. I mean, they were the ones doing the work, I was offering comments from the peanut gallery. I will say that I have some kind of open questions at the moment about what is the preferred way to learn React at this point. On the one hand, we've got the fantastic new official React docs at react.dev, and there's a wonderful tutorial sequence in there that walks you through the basics of thinking about components and rendering and mapping over lists and adding state and dealing with effects and when do I actually need useEffect, and a whole bunch of other stuff.

01:01:21 - Mark Erikson

And it's wonderfully organized. It's got in-page sandboxes and little quiz-like examples, and that is wonderful. But I do feel like there's, at the moment, a missing step right after that tutorial, and I also don't yet know how learning server components is supposed to fit into that. So right now someone could sit down and go through the new React docs tutorial and they would learn a lot, and it's really good information, but all of it is in-page in the sandboxes there. And so then I feel like someone's going to finish that and they're going to ask, okay, well, I've learned this information. What do I do now? And number one, at the moment, I don't think there is an explicit set of instructions that says, okay, here's how you go off and start a new React project. There's nothing that says, you've learned how to write components. Depending on which framework or tool you use to start your first project, here's where you literally start adding component files to that project's folder structure. And there's nothing that even, like, they recommend Next as the obvious framework to use.

01:02:48 - Mark Erikson

There's nothing that links the tutorial to, like, how would I jump into a Next project and start working on it? And Next, in turn, if you create a new Next project and just select yes to all the defaults, it basically sets you up with a server-component App-Router-driven project, unless you say no to certain options or you specifically start putting files in the pages folder. And server components simplify a few things because you no longer have to fetch in useEffect or add React Query and React Router to a project or something like that. But on the other hand, they bring in their own different set of technical constraints. So in that sense, I don't know what the right React learning path should be at this point. My mind partly says your first standalone, try-it-for-myself React project should probably still be a single-page application. But Create React App is deprecated, Vite gets mentioned, but it's just barely a passing thing in the React docs, and if you go into Next, there's all these additional Next-isms you have to learn, and if you start doing server components, that's sort of different than just traditional client-side React by itself.

01:04:20 - Mark Erikson

So I don't have any answers. I again have kind of nudged the React team and said, hey, I think these are some docs deficiencies that you really need to fill in. But I think all those things together make learning React more complicated than it used to be.

01:04:41 - Ishan Anand

Yeah, I think that's a good point. In some sense I think React has benefited from a community of people who are filling in those educational gaps historically. Like if you think back before the, I guess it's no longer beta, but the new React docs were just out of step with hooks in certain cases for a while. And I guess, you know, like we said, they don't make direct revenue off of it, and I can imagine their resources are constrained, and that's actually been a double-edged sword in that there's a gap, but it's also encouraged people to fill in those gaps in the community. But I totally hear what you're saying. It's like, how do you go from beginner to intermediate when you could suddenly go down a completely different hole and you're like, wait, I never learned any of this in the first set of tutorials. It's a really great point. Eric is another regular. Eric, do you have a question, or do you want to switch us to another topic? Great to see you again.

01:05:49 - Eric

Yeah, hi. No, I just wanted to chime in on this, like the incentives, like always look at the incentives. Like Facebook/Meta, they released this framework and they were using it internally and they released it to the rest of us, and boy did we suck it up. But they didn't give us any of their internal ways of doing things, forms and... and therefore they also don't really owe us any good docs, right? It's like they release this and hey, if you guys want to use it... I mean, in the same way that all open source, the authors don't really owe you anything. But it's just, I wonder if there's a way to manage or create an open source framework that incentivizes good documentation for... yeah, I don't know.

01:07:01 - Mark Erikson

For...

01:07:01 - Eric

[unclear]. Maybe Vercel is monetizing. Like, gosh, Next.js is cool. Hey, the easiest way to deploy Next is come pay us. But I don't know, it's kind of an interesting conundrum in the open-source world of yes, the docs suck, but who wants to make the docs not suck? I don't know.

01:07:41 - Ishan Anand

Yeah, I mean... oh, go ahead, Mark.

01:07:45 - Mark Erikson

Oh yeah. I mean, there's so many different gradients on the spectrum between, you know, I have thrown up a repo and it's OSS-licensed and anyone can grab the code if they want to; I have attempted to document this tool; I am actually trying to, in essence, market it and get other people to use it; I am trying to form a community around this. And, you know, certainly no one is obligated to put in the time and effort to make the thing usable. But to a certain extent, once a thing reaches a certain size, there's sort of a counter-obligation. The bad analogy is, like, you know, there's some fantasy authors out there who I will not name who have started series that are not finished, and they have fans clamoring for the next book to come out. And what's the implied contract between an author and their fans? I mean, the fans would be jerks if they demand the author put out the next book right now or else. On the other hand, you know, the author has sort of said, like, this is a series, it's not done yet.

01:08:59 - Mark Erikson

I intend to get the next books out. So there's a semi-implied obligation. To make the parallel here, you know, okay, if you've published the framework and you are in essence trying to get people to use it, how much obligation does that in turn impose to put more time into making it usable and documented?

01:09:26 - Eric

Where your metaphor falls down is I publish the framework and people are paying me for it.

01:09:32 - Mark Erikson

Yeah.

01:09:34 - Eric

But yeah, I get the idea that, hey, I've developed this narrative with a cliffhanger. Should I continue or not?

01:09:45 - Ishan Anand

But yes, Jason came to the stage. Jason, do you want to chime in on this or something else?

01:09:54 - Anthony Campolo

Jason, I think your thing might be glitching.

01:09:59 - Ishan Anand

Oh, is he speaking and I can't...

01:10:00 - Anthony Campolo

No, he's a listener, according to mine.

01:10:03 - Ishan Anand

Oh, okay.

01:10:05 - Anthony Campolo

You got spaced. Yeah, spaced, Ishan.

01:10:08 - Ishan Anand

Oh, I got spaced.

01:10:11 - Scott Steinlage

Welcome to spaces.

01:10:13 - Anthony Campolo

He's coming up right now. If he did have something to say.

01:10:16 - Ishan Anand

Okay. While we're waiting for him to come...

01:10:20 - Jason

Sorry.

01:10:21 - Ishan Anand

There we go.

01:10:21 - Jason

Twitter client crashed. And when I rejoined, I was a listener again.

01:10:25 - Scott Steinlage

I didn't have any...

01:10:27 - Jason

I didn't have any pending questions or remarks, but I requested to come back to be a...

01:10:32 - Tejas Kumar

Because you.

01:10:33 - Anthony Campolo

You were requesting to clear your good name. Your audio is also totally jacked, so...

01:10:41 - Jason

Yeah, I'm on a bike ride right now, so I was just trying to be a listener.

01:10:47 - Scott Steinlage

Enjoy your bike ride.

01:10:49 - Ishan Anand

Maybe the spicy take I'll propose is maybe our bar for what a good open source project has been inadvertently raised by a lot of companies that were doing it with a financial incentive and VC-backed expectations. So the succinct way to say this is, like, great open-source documentation was a zero-interest-rate phenomenon.

01:11:23 - Tejas Kumar

Right?

01:11:24 - Eric

Well, and by selfless jerks like Mark.

01:11:32 - Ishan Anand

But I guess what I'm saying is our expectations are high because of the amount of effort that went into it, and in some cases was incentivized. In Mark's case, actually, it makes sense. They're actually filling a white space that is being left open by the creators of the framework, in a sense. But I mean, that's really what I'm getting at. It's the same thing you were saying earlier on incentives. It's like that famous, either Buffett or I don't know, one of those manager guys, was like, show me the incentives, I'll show you the outcome. And now we've seen in the current macroeconomic environment there's less funding for that potentially in the market, and I think it'll be interesting what happens to the ecosystem.

01:12:28 - Mark Erikson

All right, on that note, I need to actually call it a day and try to get a little more actual productive stuff done here at the day job. So thank you all for the time.

01:12:37 - Anthony Campolo

Thank you.

01:12:38 - Jason

Thank you.

01:12:38 - Scott Steinlage

Thank you so much, Mark.

01:12:39 - Jason

Thanks, Mark.

01:12:40 - Scott Steinlage

Yeah, greatly appreciate you, man. And don't forget to follow Mark. And if you want to see him in person, live, he's going to be speaking at React Rally. And there's that discount there, 50% off for the first three people only. So if you haven't grabbed it yet, and if they're not gone yet, I have no idea. You might want to get it now if you're planning on trying to attend React Rally. But we're sticking around here to the end, and I just want to go ahead and I'll throw in the comments here later, as soon as we jump off, another link that I have. So if you couldn't get the 50 off and you weren't able to jump on that train, then it's okay because I still got something for you. React Rally hooked us up and they're letting us give you 35% off, period. So that's pretty crazy. How awesome is that? If you haven't gotten your tickets yet, try this 50% one. If it doesn't work, I got a 35% one for you later. All right.

01:13:44 - Ishan Anand

Okay. By the way, we should remind folks, what are the dates for React Rally and where it's...

01:13:51 - Scott Steinlage

Yeah, that's probably a great, great idea. I don't even think we mentioned it in the beginning, did we? So it's Thursday, August 17th, and Friday, August 18th, and there's lots of great speakers, including Tejas, who was in here earlier, Mark, who just dropped out. So Tejas Kumar, Mark Erikson, several names you guys probably know, Kent... Kent C. Dodds, Shirley Wu. I don't know, I'm just kind of throwing some random names out there that you all might know. But yeah, some exciting ones. Monica Powell, Ben Holmes, you know, Astro's in there. Good stuff, right? Lots of great people to hear from. And it's in the beautiful city of Salt Lake City. So yeah, lots of wonderful views on views, if you want to go.

01:14:40 - Eric

All right, I'm sorry, how can you say Kent Dodds?

01:14:43 - Scott Steinlage

C.

01:14:45 - Eric

There you go.

01:14:47 - Jason

Please.

01:14:47 - Scott Steinlage

You know what?

01:14:49 - Tejas Kumar

Geez Louise.

01:14:49 - Ishan Anand

Don't.

01:14:50 - Eric

Don't swear like a Mormon.

01:14:51 - Tejas Kumar

Come on.

01:14:51 - Scott Steinlage

Yeah, I mean, hey, he's the one who suggested that we hook up and chat with React Rally about doing some things with them. So thank you, Kent, for the connection with React Rally. We're excited for it. We did a collaboration with Remix too, and we had a great time there doing that. Onward and upward, folks. Don't miss out on your chance to network with some great folks and learn something.

01:15:23 - Ishan Anand

Now, I want to know, what does the C stand for?

01:15:26 - Scott Steinlage

Yeah, I'll ask him the next time we get him on one here.

01:15:29 - Bro Nifty

Yeah, it's for the rhyme. You have to say K, C, D. So it all goes together.

01:15:34 - Anthony Campolo

Right.

01:15:35 - Bro Nifty

You just add that just to rhyme it.

01:15:37 - Scott Steinlage

Yeah.

01:15:38 - Jason

So now he's C, maybe.

01:15:43 - Tejas Kumar

that's it.

01:15:44 - Scott Steinlage

Yeah.

01:15:44 - Jason

Right.

01:15:45 - Scott Steinlage

Yeah. And now he needs to show up to KCDC so he can... yeah, okay.

01:15:50 - Ishan Anand

I knew somebody whose last name was Webb, and I was so jealous.

01:15:56 - Scott Steinlage

Awesome.

01:15:58 - Ishan Anand

So we're coming towards the end, but maybe we'll cover this in a future episode. Anthony, in the great newsletter he puts together, and again, go to JavaScriptJam.com, you can subscribe to the newsletter, Anthony does a story of the week in the JavaScript ecosystem. And, you know, Anthony hosts another podcast. He's also in the core team of RedwoodJS, so he's got his ear to the ground to a lot of stuff, and it's definitely something I recommend subscribing to. I've learned a thing or two myself. But one of the stories of the week this week was, you know, is the Jamstack dead? And I'd love to get either Anthony or any of those speakers on their take on that story. And if you missed it, the news is basically that the creators of the term are moving on. I don't think there'll be a Jamstack conference. The Jamstack Discord was shut down, and there are a couple posts about this.

01:17:03 - Anthony Campolo

Yeah. But I talked to Brian Douglas. His take was that he may even rebrand Jamstack Radio. So maybe that JS Jam will be the sole standing Jamstack left. It will be all mine. I will be Mr. Jamstack.

01:17:20 - Ishan Anand

Maybe you can get them to sell you the trademark.

01:17:22 - Anthony Campolo

I'll give you $10.

01:17:28 - Ishan Anand

But yeah, do you want to... I think I probably described it. Do you have anything to add for context? And then we'll see if anybody has any comments.

01:17:35 - Anthony Campolo

Yeah, I mean, I think this is probably a larger discussion than we can have right now, but I think there's two opposing viewpoints. One is that the term is dead because Jamstack was not a thing that we should have been doing in the first place. And the other one is the term is dead because we need to move beyond the term because Jamstack is just how everyone does everything now. So the consensus seems to be the term is dead. That's like the one big takeaway. But whether the approach is dead or not is still an ongoing conversation. That will probably be an ongoing conversation for many, many years to come.

01:18:13 - Ishan Anand

Yeah. Oh, go ahead.

01:18:16 - Bro Nifty

I wasn't going to say anything more important than you.

01:18:21 - Ishan Anand

Go ahead.

01:18:21 - Scott Steinlage

All right.

01:18:22 - Bro Nifty

I was just going to say maybe it's just... I'm sorry, Ishan. I apologize for talking over you real quick. Just real quick. Maybe it's CDN and bring your own APIs now.

01:18:35 - Anthony Campolo

Yeah, that's the thing. There was a term, because describing it sounds clunky. So it's like, what's the new term going to be? Is the question for me.

01:18:44 - Ishan Anand

It's funny you say CDN and bring your own APIs. I gave a talk, which is also in the newsletter actually, like two years ago, and it was originally titled Jamstack Identity Crisis. It was clear there was an issue brewing here. And when Brian and I talked, he's like, there's some negative pushback on it. I think we should rename it to Evolution. And I think the old URL...

01:19:12 - Ishan Anand

If you look at the URL, even though the title might be Evolution, the URL of it I think still says Identity Crisis, at least on cfe.dev, and it does feel like it was brewing. And I actually gave a very similar definition to what you gave, which is, you know, bring your own CDN and APIs. It was slightly different than that, but basically that a lot of it rested on the edge or CDN technologies, which are clearly growing in importance in the community. There's another JavaScript Jam episode we did, which you can find on our... if you go to the podcast, yeah, we had a bunch of people debating what is Jamstack. And that was two years ago, the same time. And we had, you know, Brian Rinaldi, who's the editor of Jamstack. We had Jeff Escalante, who basically is the other side of what Anthony said, the two viewpoints. And it was just interesting to listen to and reflect on, given this week's news. And so I actually went back and rewatched it. And I'll say this: Jeff has been remarkably consistent.

01:20:29 - Scott Steinlage

That's true.

01:20:30 - Ishan Anand

In his position. I would describe his position as more that it lacked technical meaning. And like you said, Anthony, I think there's a lot to say here. I've been reflecting myself on it. At the time, my statement was very much that, and I said this, which is, it's going to be like HTML5. It's a way to separate the past from the present, and eventually it'll kind of wither away and it will both win and lose. And it seems like that is what's come to pass.

01:21:06 - Scott Steinlage

I liked the flat-screen TV analogy. Like everybody was all about flat-screen TVs and everybody talked about them and it was the thing. And then nobody talks about flat-screen TVs anymore, but everybody has flat screens in their homes everywhere, right? Yeah. You know, and real quick, just on cfe.dev, it just made me think of something when you brought that up. Ishan, someone in the audience here, Nick, Nicky T, Mick Taylor, he has a new show, a talk show on CFE Dev, like one of the talk shows there with one of the four, and it's Two Full, Two Stack.

01:21:39 - Anthony Campolo

The best name ever. I absolutely love that name.

01:21:44 - Scott Steinlage

Too Fast, Too Furious, right? Two Full, Two Stack. I love it. So yeah, be sure to check him out on there. I can't remember the dates he's doing that, but let's see if I click on it. It'd probably tell me. But he's got one coming up August 24th. So "WTF? What the Form?" is next on August 24th with Two Full, Two Stack with Nicky T. So check it out.

01:22:07 - Anthony Campolo

Awesome. Well, I'm going to go back to my loud, noisy restaurant, so I'm going to sign out here.

01:22:13 - Scott Steinlage

Awesome. All right, anybody have anything to say about what we just brought up? And if not, it's okay. We can continue this conversation next week. I'm sure there'll still be lots of talks going on about it.

01:22:27 - Ishan Anand

Yeah, maybe we can get the old gang back together from the debate session.

01:22:33 - Scott Steinlage

That's interesting. Although we do have two guests next year... or next week as well. Yeah, we do.

01:22:39 - Ishan Anand

After that maybe.

01:22:40 - Scott Steinlage

Yeah, after that, probably, yes. So it'll be good. It'll be good. So be sure to join us next week as well. Like I said earlier, if you got value from anybody up here on stage, click on their name, follow them, because you're probably going to get value from them in other places. Give JavaScript Jam a follow. Go to JavaScriptJam.com, sign up for that newsletter. We were just talking about all the meaty bits in there, the spicy takes that Anthony puts together in there. You know, the latest in the web devs, for sure. Check it out. That sounds like a great newsletter: the latest in the web devs. No? Okay. Terrible title. Anyway, thank you all so much for showing up. We love y'all.

01:23:21 - Scott Steinlage

We appreciate y'all, and come join us next week and we will be chatting it up with David Khourshid. I don't know if I pronounced that right, but... and Shirley Wu. So two awesome speakers from React Rally. And we're going to be having similar conversations to what we had today, but also much more. So be sure to join us, same time, same place, next week, Wednesday, 12:00 p.m. Pacific Standard Time, to have a little conversation. And if you want to ask them question stuff, you know, show up, so you can do that. It'll be fun. But with that being said, I think that's the end, folks. That's all she wrote, or he, or we. Yes. We did it. We love y'all. And we'll see you in the next one.

01:24:16 - Ishan Anand

Thanks, everyone.

01:24:17 - Scott Steinlage

Yeah. Thank you. Thank you all. We love you guys. Great. See you in the next one. Peace.