The Untold Story of React: How a Broken Ads Tool Changed the Web
NextDev
Channel
Interviewed Person
Tom Occhino
Description
In this episode of NextDev, we explore the surprising origin story of React—the revolutionary JavaScript library that changed front-end development forever. Subscribe for developer-first conversations around modern stacks, tools, and the future of AI. 👑 Guest Links Website: https://www.tomocchino.com/ X/Twitter: https://x.com/tomocchino 🔗 Stay Connected: Website: https://nextdev.fm YouTube: @nextdevfm X/Twitter: https://x.com/nextdevfm Twitch: https://www.twitch.tv/nextdevfm For developers, by developers. #NextDevFM #ReactJS #FrontendHistory #OpenSource #JavaScript #DeveloperJourney #DevTools #Fullstack #FacebookEngineering #ByDevelopers #ForDevelopers #MCP #EpicStack #Innovation
Transcript
We had a really complicated client side application. No one wanted to touch anything. Started to see the magic. If it could be fast enough, my gosh, the developer experience here and the end user experience are both just dramatically better. [Music] Let's fast forward to React. When and how did that happen? Yeah. Okay. So, 2012ish. Mhm. One of the problems we were having was inside of our ads or we had a really complicated client side application. We
were transitioning from a server-driven primarily server-driven ads manager. Actually, Paul Shen, who's now at OpenAI, Nanga is still at Meta, like they they worked on this primarily serverdriven ads manager, but we needed to add a lot of interactivity. And as we added more and more interactivity, this thing just it just like started to fall over. So, we then moved to a completely client side model really. And the client side ads manager app was it was just massive, right? It was built on basically a traditional
client side MVC where you'd have these models and you'd have these views and then the controller would like glue things together. But the problem was the models were so fat and they have so many incoming dependencies that you would make a change even when this app was not that massive. You'd make a change at one place in the app and it would have all of these downstream cascading consequences. And so we just like we stopped being able to scale. The worst part though than the application becoming bloated and slow was that the team no one wanted to touch anything right like oh god I can't touch that. That's
the core model like I'll just go over here. So they kept adding more and more and more code and more bloat and you know causing a lot of incidents and a lot of problems. So Jordan Walk was in the ads uh or at the time and he's like there's got to be a better way. And his idea had always been, look, you need to shove this data into some templates or something in order to generate the initial render, right? And why can't you just whenever anything changes do that again? Why can't you just rerun the initial render? And the
problem with it was while you'd lose state uh if somebody typed in a text box, you just blew it away and replace it with a new text box. You would lose uh you know flicker, there'd be some some jumpiness and some things. He's like, but conceptually I don't have to think about look at all this code I delete. I just delete millions of lines of code. It's insane. So, we actually were already using that technique for less stateful interfaces. Whenever you This is like circuit 2012 again. Whenever somebody would sign online and actually I think we did this via polling every couple of seconds.
Whenever your buddy list changed, we would rerender the entire body list from scratch. Yeah. We would just hit the back and we say like who's online. Eventually, when it became pushed, great. It's push now. But the same thing applies. It's like, hey, there's an update. Yeah. You could go in and say like, "Okay, I need to remove this DOM node and add this DOM node and update this yellow dot from yellow to green." Or you could just say, I don't know, just rerender the thing. Yeah. So, we we were already using this technique. So, I connected sort of like Jordan Walk and Jing Chen. Um, and Jing was working on chat at the time with Adam Wolf and a bunch of other
folks and and they're like, "Look, you know, this is working pretty well. There's a couple bugs and Jordan kind of had that same idea for this rerender everything from scratch." React was a or I guess fax.js JS was an exercise in how do we make it so that conceptually this is the model but then we can make it much more efficient and much more you know delightful of a user experience. He had kind of passed this idea around the ads or for a while and everybody was like this doesn't fit into our road map. How's this going to make us more money? Like I don't know what this is. I've never seen this. And then you know
eventually one of the engineering directors reached out to me. He's like yeah you're doing this JavaScript infrastructure thing. You know can you talk to this guy Jordan and see what this is about? When Jordan came to tell me about it initially, I was kind of like, "No, we don't have time for this." I did the same thing. Um, but then I kind of gave it five minutes and he sat with me and we kind of went through it and I I started to see the magic and because, you know, we brought a couple of uh additional folks in and people started to get it. They're like, "Look, I don't know if this is going to be able to be fast enough. if
Video Details
- Duration
- 7:46
- Published
- July 12, 2025
- Channel
- NextDev
- Language
- ENGLISH
- Views
- 252
- Likes
- 16