Back at React Summit in New York, KBall & Nick sat down with Tom Occhino & Shruti Kapoor for more fascinating conversations.
Tom Occhino, a key figure in React’s history at Facebook (now Meta), reveals the origin story of React, which began when an ads engineer presented a revolutionary approach to web UI rendering. The discussion extends to React’s evolution through Next.js.
Then, Shruti Kapoor breaks down React 19’s major features, including React Server Components (RSC), the new compiler implementation, and enhanced APIs that promise to streamline development workflows.
Phillip Carter: Yeah. So it was kind of funny, because after we – basically, one of our major success metrics was “Well, how many users are using the new net?” We reached about 5 million, and that was sort of like a major benchmark, and we hit it. And I just had a conversation with my PM director, and I asked him “So what’s the next big thing? I mean, this was really ambitious, and we knocked it out of the park. What’s the next big one?” And he’s like “I don’t know.” And that was because he was switching jobs over into another department, offered a VP position at Microsoft. I’m like “Oh, that’s why you don’t know. Okay. Well, I guess maybe I’ll look around too”, because I really liked the team that I was on, but you know, you complete an ambitious arc and you’re like “Okay, well, let’s kind of look around what’s out there. Maybe there’s something new.”
There’s clearly a lot of interesting stuff going on in developer tools outside of programming languages… So like looking up stack, what are the things that are there? So I ended up talking with some folks at Honeycomb, just because I didn’t know anything about observability at all. But I was aware of Liz and Charity, and I was aware of like a general consensus among some of the .NET developers that I knew that Honeycomb was doing things the right way, or the better way, or whatever. I’m like “Okay, cool. Let’s explore. What’s the worst that can happen?” Like, it’s not for me? Alright, cool.
So I chatted with them, kind of did the whole interview loop… I really liked the people, and was kind of sold on some of the initial vision. Because Honeycomb - it came out before Open Telemetry, but it was still very, very early stages when Open Telemetry was formed. And Honeycomb as an observability tool is fundamentally different from the rest of the market. It has this ambitious goal of “We really want to help developers reshape fundamentally the way that they introspect their systems”, and this gets from super-high level, like how you do an analysis workflow… Instead of saying “Oh, I’m going to look at my logs, and then I’m going to go look at traces that correspond to that, and see if I can find a match…” And like “Oh, I have this metric that says it’s up. Alright, cool. Are there any logs that relate to this time range, or something?” Kind of a broken debugging flow compared to what we do. And that kind of attracted me.
[00:28:08.25] But then at the same time, they’re like “Well, there’s also this whole other thing with Open Telemetry”, where regardless of our product shape or what we think people should be doing best, there’s this open standard that’s evolving, that is ambitious enough that people – it captures the majority of what people care about. And we have some pretty big customers, who are like - them continuing with Honeycomb is pretty contingent on us being quite deeply involved in the project.
So one of our larger customers, quite literally, in clear contract terms, was like “You need to be significantly involved here, because we’re taking a bet on standardizing on OTel, and we’re taking a bet on using Honeycomb across all of our teams. And I do not want one of those pillars to falter in some way. So I trust that you care about your business, but do you really care about OTel? Figure it out.” That’s what the role was scoped to, was “Okay, we’re going to take a bet on OTel. Great. We did it. Mission accomplished! But what is that bet? What are we doing, though? Where should we point our time, and our limited number of engineers we have? Should we hire for this? For how many? What are the most important things to invest in? What are the major problems that people have?” All the big stuff.
And I was just given the mandate to go and shape that into “Where do we point our force vector?” if you will, and “How do we keep doing that?” And then how do we start, a) trying to start skating where the puck is going, of like the project is evolving in this way… Can we make sure, at least at a very minimum, does the Honeycomb product not get destroyed by this thing in some way? We don’t want to be caught by surprise, in some capacity. But then also, b) okay, well, we do have a perspective here. How much of our perspective on observability aligns with the overall perspective of Open Telemetry? How do we make these things come together in a way that fits very well, and works for everyone involved? And how do we ultimately demonstrate that we are leaders in the project, instead of just consumers of this open standard? That was the main thing. And that’s what I did for about 3 years or so.
And being a startup, I kind of had my hands in all kinds of different places, but I was always very fundamentally rooted in being an Open Telemetry maintainer, which I’ve been since - -gosh, I think like the end of 2021… And trying to fix all kinds of problems that like “Oh, someone’s trying to use Open Telemetry plus Honeycomb, plus this language, plus this environment that they want to run in. It falls over in this way. Okay, great. Is that a legitimate bug? Is that a documentation problem? Is that like they wanted to use an API in this way and they couldn’t figure it out, and we need to add a more convenient API to something to just make it more obvious for someone how they accomplish something?” Just multitudes of that kind of work over the course of the years, and just being much more involved in the project and trying to shape what are the things that we try to make good in this big open standard that none of us have the time to really work 100% on all the time. And yeah, I don’t know… Kind of [unintelligible 00:31:10.17] stuff, but did that. Still doing that, frankly.