Tom Occhino, now Chief Product Officer at Vercel, tells Ben about how he contributed to the development of React at Facebook and the contentious decision to make React open-source. They also talk about what community feedback has been like on Next.js 15, Vercel’s GenAI web development tool, and how Vercel is rethinking IDEs.
Want to learn more about the early days of React? React.js: The Documentary gives you the full story from the perspective of the developers who created it.
Vercel is a native Next.js platform.
v0 aims to democratize software development for non-technical users. Check it out here.
Listen to our recent conversation with Vercel’s VP of AI.
Connect with Tom on LinkedIn or X.
Kudos to Stack Overflow user Sodruldeen Mustapha, who earned a Lifeboat badge by answering How to remove the environment variables from Laravel Debug?.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm Ben Popper, Director of Content here at Stack Overflow, and today I am joined by Tom Occhino, who is the Chief Product Officer over at Vercel. The Next.js Conference is coming up– Thursday, October 24th in San Francisco. If this episode comes out before that, maybe you want to attend. If it comes out after, maybe we'll have shared some news about it. But we're excited to chat about all things React, what's going on with Vercel and Next.js, and about v0, which is the generative framework that folks can use to get started building all kinds of cool web layouts, designs, pages, you name it. So without further ado, Tom, welcome to the Stack Overflow Podcast.
Tom Occhino Thanks so much for having me on the show. Great to be here, Ben.
BP So Tom, just for folks, give a quick flyover. What was it that got you into the world of software and technology and then what brought you to Vercel?
TO So early days from the first time we got our family computer I loved to tinker, and eventually made my way into HTML, CSS, and early days of JavaScript. So web development became my passion. I went to school for software engineering, computer engineering. There was an electrical piece that I was less interested in. Eventually I just found myself making websites and that was my real passion, and so I eventually got involved in some open source JavaScript way back when, and ultimately ended up landing a job at a company called The Facebook.
BP Oh, I've heard of that place.
TO So that was my early days. I started out as a software engineer there in 2009.
BP So at Facebook, you went from a software engineer IC to an engineering manager and then to a director overseeing the React group, which includes React Core and Native Relay projects. Talk a little bit about that progression. What was it like being an IC? How did you enjoy, or not so much, the transition to management? And then when you were there as a director, talk about overseeing this technology that so many tens of millions of people use every day.
TO So from the beginning, I started out just working on lots of different user-facing products. At the time, we didn't have mobile apps yet so it really was the majority the desktop website, a little bit a complimentary experience on the mobile web. But I focused on building user-facing products and things like the ‘what's on your mind’ box, I kind of helped build the first version of that, and search and mentions. If you've ever typed an ‘@’ symbol text box and seen a dropdown, I kind of helped build the first version of that. And eventually what ended up happening was that we found a lot of repeated patterns. We built UI component libraries or design systems as they're called today, and we found these repeated patterns in a lot of our JavaScript tooling. So my transition into management actually ended up being inside of a team we called ‘product infrastructure,’ and within that we created a small sort of JavaScript infrastructure team and we were responsible for all of the shared libraries and the module system and how we load static resources and bundling and things like that. That ended up being the place where the first conversations, the earliest days of React ended up happening. So in our advertising org, we were building some pretty sophisticated software and the existing tools that we had, especially as our teams were growing, for building and deploying that software, I think weren't really hitting the mark for us. And so this young enterprising engineer named Jordan Walke kind of had a better idea for how to do things. And you can watch the React documentary if you want the full story of the background there, it's a really good creation story, but eventually this thing that would eventually be called React was born, and my team was the place where we ended up building up a team and developing it. Once it started to pick up traction internally and the team got bigger, I eventually grew that team into an org. I think by the time I left, the React org was somewhere around maybe just north of a hundred people working on everything from our web technologies and JavaScript frameworks and things like that.
BP Can you talk a little bit about how it transitioned or if it began originally from something that was addressing needs in-house and was the brainchild of an engineer with some ideas that they wanted to be ambitious about, to something that is open to the public community and how you share both the responsibility of guiding it internally with meeting the community's needs, listening to them, and letting them also accelerate its development?
TO I love that. I think the reasons that we were excited to invest in it in the beginning became very different than the reasons we decided to continue investing in it over the long run. So in the very beginning, we saw something that made it easier and more fun to manage some of the larger applications we were building. So the classic problem with a big application is that you have lots of models and lots of controllers and these things fit together in weird ways, and as a single engineer you can't keep the whole system in your head for very long. So React introduced this idea that the component is the right sort of boundary for concerns. I can handle everything inside of my component, we could grow our teams more easily. We were really excited about the way that this thing was scaling. But the reason that we kept investing in it and that we sort of almost doubled down was that our code was higher quality when we were building it this way. Once you have engineers focusing on doing fewer things better because they're contained inside of this component boundary, we saw that with our software we were iterating faster, we were shipping with higher quality, and there was higher satisfaction. There was a whole other shift about should we even make this thing open source? Initially, there was a lot of opposition internally to open sourcing this. We had a bunch of former Microsoft folks who really didn't believe in open source and almost went on this sort of crusade internally to say, “No, we have to share this with the world.” And then spoiler alert, when we ultimately did share it with the world, I think our initial messaging was just not very good. People didn't really get it and I don't want to say they booed us off stage, but it took some time. We had to give them five minutes and a couple other conference talks before it started to pick up.
BP It's really interesting to think about a technology that is now so widely used and used not only for large organizations, being this thing that you created, as you said, to try to manage things that's at the hyperscale level. So I think that's pretty interesting as well to think about that it was there to solve a problem and then what you realized is, “Oh, it just makes us better.” It's this broken windows theory of, “Oh, we're coming in with less bugs. Our developers are more happy. Things are cleaner. They understand what they can focus on and get in the flow state.” You could be any size and that's a good thing.
TO Absolutely. And I think one of the things I really liked about React in the early days was that I got to focus on the things I wanted to focus on which was a bit more fun. There's a whole generation of software developers that will never have to think about imperative mutation of their views. This is fantastic. The whole world does declarative views now. And so I think early days it was a little bit more fun and then we saw that it scaled a bit better and then we learned as we went. And I think eventually we learned that in order to actually really fully take advantage of this model, you needed to be able to influence both the client, which is where it started, and the server, which is one of the reasons I was excited about Next.js. This was probably the first external –so external from Facebook– the first framework for React that really had an opinion about how you do data fetching and had a very, very simple zero setup server-side rendering without having to configure a bunch of things manually. So that's the connection to Next.js– continuing the elegance and the delight that we had with React and extending it to the capabilities of the server.
BP All right, so that brings me to I think the second part of this episode. We've covered your background and React. Talk a little bit about the relationship between Next.js and Vercel, we know that React is included in that, and what sort of drew you to making the jump from Facebook to a much smaller organization.
TO Ultimately, when I left Facebook in June of 2021, it was great. I had hired two leaders for the two sides of my org and I left on very good terms, I still talk to the team often. I wasn't initially planning on going back to work anytime soon, but I ended up seeing Vercel as a place where I could kind of continue a lot of the same objectives I had and a lot of the same work that I was doing but in a new context with people that I was really excited to work with and learn from. And the thing that I really liked about Vercel was that one of the downsides of Facebook was the way that we were using React was kind of very specific to Facebook's infrastructure. And that infrastructure is not really available to the rest of the world, so you have this sort of bespoke relationship between the framework and Facebook's infrastructure. And everybody else that wanted to use React had to connect it to their infrastructure in their own way. So the thing that I really love about Vercel and Next.js and the relationship between them is that we know to innovate in this space we need to have influence over both the server infrastructure, the managed infrastructure, and the framework, and we want extremely high cohesion between these things but loose coupling between these things. Actually, if you go back to Pete Hunt's original JSConf EU talk I think from 2013, this is one of the principles that React outlaid, which was that we want to build these things– and he wasn't necessarily talking about the infrastructure side yet– but we want to innovate with full control end to end. And then once we prove that something's going to work and it's going to deliver real value for developers and for users, we want to generalize it. And so the idea behind Next.js at Vercel is that we build the framework and the infrastructure in tandem, we make it so that these things work really well, and then we generalize in the framework. So we want to make sure that Next.js works really well for self-hosting. We're really working more and more with the community about how to get Next.js working on other places where you host, but the thing that I really love about the relationship between the two is that when we build them side by side, we can make changes to the whole stack. We don't have to hold that constant over there or hold this constant over here. And I think the result ends up being this idea that Next.js as a framework can work in lots of places. Vercel can be the best place to host lots of different frameworks, and programming languages in fact, but together they're sort of designed to work as well as I'd say Android on a Google Pixel. These two things work really well together.
BP There were two sort of lines that were sent to me to spark this conversation, and I think both of them get to what you're saying. I'd like you to maybe elaborate on them a little, and they also get to that heart of commerce and commercial business versus open source. We don't build Next.js to make money, we make money to keep building Next.js. Okay. And then leverage Vercel infrastructure as a testbed for new innovation, but make that innovation available to the rest of the world. And that goes right back to what you said about how at Facebook it was specific to this infrastructure which isn't necessarily applicable to many people or shared in a way that other people can pick up on, although they have open sourced many things over time in the AI world and in the data center world and in other places. But just talk through those two things and I'll play the skeptic here. You're not in it to make money– sure, sure. But if that's the mission and the maxim, how do you do it in the way that allows you to do both– continue growing the company and thriving with the community and allowing the technology to be agnostic, it's open to everyone?
TO So I'll take the second piece of that first. I think that we have this concept of framework-defined infrastructure, and the whole idea behind this is that I believe that most of the time that humans spend provisioning infrastructure– provisioning compute, scaling their systems– I believe that most of that work is undifferentiated. Around here, I call it ‘undifferentiated heat loss.’ And it's very hard to do this, but if you can change developer behavior subtly such that you have the ability to deploy based on the code that's written, we can just obviate the need for all of that manual orchestration and configuration. So I love to live in a world where because I've written my code a certain way, infrastructure can be automatically provisioned for me. I don't want to think about that. I'm a front end person, I like to focus on my end user experience, etc. So that's kind of part one. In order to enable that, we actually really do need to have an influence and strong opinions about how the infrastructure should be provisioned. What do I see on the front end? What do I see from the framework that enables me to provision infrastructure in a certain way? But it turns out that in building the primitives that can automatically scale and can automatically deploy the right types of compute in the right regions no matter where your customers are and can cache as close as possible, in building a lot of this stuff we ended up building a bunch of general purpose primitives that end up working really well for any workload. So I think Vercel is probably the best place to host Remix apps right now and a bunch of other frameworks. And if you want to get whatever you've built out to the world, you've got to put it somewhere, so it ends up being a pretty good business to be able to serve and render and compute even these really sophisticated workloads. So that generates the sort of business side, and that then creates this sort of flywheel of investment back into the framework that ends up driving more innovation into the infrastructure and the framework itself, which then begets more. So we've created this sort of flywheel. And this is adapted from, ‘we don't build products to make money, we make money to keep building better products,’ but I think the same is true about Next.js. We're not building Next.js explicitly to make money. We're running this business in order to keep funding Next.js, and that'll become more and more true in the fullness of time.
BP We're recording this on the 16th of October, and Next.js 15 RC 2 had some details shared yesterday on the 15th, and there was a lot of stuff that I remember from my last visit to the conference, but Turbopack and then a bunch of other things that you're working on, async requests, server action static indicators, things that are an improvement for everyone in the community that you have the resources to invest in, but also that is based on feedback from the community. Can you explain a little bit how that works?
TO The biggest piece of feedback we've gotten from the community as of late is this idea that all of the sophistication of Next.js, all of the sort of underlying complexity of Next.js, it's not really progressively disclosed to you. You have to confront lots of different concepts from the beginning. So one of the things we've been iterating on is ensuring that the simple case stays simple and then the sophisticated case remains possible. And so what we'll talk about a little bit at Conf is this idea of, “Man, I wish that I could just fetch data and render, and then when I needed to cache that data, I could just use cache,” so sort of alluding to something we'll talk about at the conference. And then the other side is that we believe that iteration velocity ends up being the solve for all known software problems, and so we've been investing in Turbopack, which is our bundler and compiler that really with fast refresh, I want to live in a world where I make changes and I see those changes instantly. And when I want to deploy, I can deploy really, really quickly. Builds are super fast. So we've been iterating on that as well. The theme across the keynote here is all about the steps you take, the tools you need in order to make it work, and then the tools you need in order to make it right, which is that iteration velocity with Turbopack, and then the tools you need in order to make it fast for your customers. And so that's a Kent Beck callback from way back in the day, but we're bringing it back for the keynote.
BP So you mentioned that one of the things you really like is to enable people not to think about something that to you seems generic. You talked about that heat loss. I was just looking up an old Stripe blog I think from 2018 that asked developers what was going on with them and accounted for it and sort of came away with the idea that almost 40 percent of this is ‘toil work,’ they called it, things that developers would rather not do if they can avoid it. And now we live in a world where increasingly maybe they can because Gen AI can do these things. So this is a nice transition to v0. I know at this point it's helped folks make millions of designs, helped nontechnical folks like myself from a marketing department cook up a fairly complicated website or product page. Let's talk a little bit about what's going on with that. And again, I think it's a nice intersection with the conversation earlier because now you're making it available to teams and organizations and so that's the level where if you want to have this strict security and this compliance and this governance, great, we'll help you with that, and you'll pay a little something on top.
TO So I'll connect both v0 and managed infrastructure to the same sort of principle I have or the same thought that I have. It's a little aggrandizing, but bear with me for a minute. I believe human progress happens when you take something that only a small number of people can do and you make it so anyone can do it, and then you make it so no one has to. And so the idea of provisioning compute– it used to be that I had to rack mount servers and I needed to buy a building and I needed to run network lines into that building and then line up machines, maybe build or buy machines, and eventually AWS comes along and GCP and Azure DevOps and we've made the ability to procure compute that you just log in and there it is, you can get it right. And now with solutions like Vercel, I’m biased, now no one has to do that. You just focus on your app and we'll provision all of the compute for you and do all that stuff. So that's kind of the human progress evolution. v0 is really interesting because whether you're already a software developer and normally maybe you have to look up some documentation about something like how this works or whatever, you can become now a super software engineer because all of the tools are in one place and it enables you to move faster. But again, related to the human progress thing, we took something that a small number of people can do and we've opened it up to a lot more people in the world. Now anyone can get started as a software developer. And I think the thing that we're going to find with v0 is that it's not just a good place for existing developers or people who are curious about generative AI or generative UI as we call it, it's actually going to be a great way to learn the principles of software. It's going to be a great way to learn software development. So any sufficiently advanced technology is indistinguishable from magic. The first time I used the new version of v0, I was absolutely blown away. I'm like, “This is magic!” I don't have to think about all of this stuff and I don't have to look at a blank screen anymore. I can get my idea out there and I can iterate in place super quick and build something that actually feels pretty good. And is it 100% there yet? No, I have more work to do, but the barrier to entry went from low to on the floor.
BP There was a time when you were probably working after you graduated from school making websites and designing them for people. It required that. And then there was kind of the drag and drop era of modules and buttons and things for people who worked on a Squarespace or WordPress could do it. And now there's the natural language version, which is kind of this beautiful idea of just, “I express my idea and it does it.” I recently worked with a Gen AI agent, I won't say who, and it will immediately make a website for me when I ask for it, but it had this strange problem where then I would say, “Okay, this looks great. Can we just change the font from this to this? And can you shrink the header and increase the size of the logo?” And it would say, “Sure, no problem.” And then it would come back and have redone 75% of the website and changed all of these other things because it's nondeterministic. And I would say, “Okay, appreciate it. Please only do exactly what I say and nothing else,” and maybe one out of every two times it would do just that, but the other time it would, again, just rewrite the whole website from the ground up. So it was overeager to be that starting point partner where I give it an idea and it throws everything up and then I guess I'm supposed to work from there. Does v0 allow you to do that kind of tweaking? I know in the stuff that was shared with me, you talked about debugging and tests and all kinds of other stuff, but when you want to get granular, do you continue working with v0 or is v0 that initial sketch and then you step back and you work on it yourself?
TO So one of the old features that I miss from the original version of v0 that's coming back is this idea that you can just pinpoint a specific element or a specific portion and only have a conversation in the context of that thing.
BP That’s what I needed.
TO So you're looking at your generation and you click on the font and you're like, “Do this.” The other thing is that we really went back and forth. Let's say that an icon is wrong and it generates a sidebar for you. You could tell the LLM, “Make this icon of that icon,” or we could give you an icon picker right in the thing. So we're talking about and exploring what the right developer experience is here, what the right user experience for the tool is, but we're definitely going to find the right balance between “Do a full generation” and “Only do this iteration over here.” The other thing that I think is really powerful and that we’ll back into very soon is, when we rolled out v0 for teams and for enterprises, one of the things we teased that's coming is this idea that, number one, v0 right now just exists in this box in the browser in this window, but what happens when there's lots of files in your app or you need to make changes to multiple files that are on your file system? And so we've been working on that iterative workflow so that v0 is not just about getting started and then ejecting, it can be your tool that you use to keep going. But the thing I'm most excited about is what you said. There's so many other functions inside of an organization that now can build something pretty quickly with really high quality and good usability that maybe don't have a traditional background. And so there'll be some, “Here's a quick tool that I built,” and there'll be some sort of, “Here's a long-lived tool that we're going to keep iterating on as a team,” but we're far closer to the beginning of this journey than we are to the end.
BP When you say go from sort of the sketch pad and the place where I start this thing and then I have to move over here because my application or my service is more complicated to, “Hey, you can stick with us as this thing progresses,” does that mean developing into its own little IDE or what are we talking about here?
TO It kind of is going that way naturally as we add more. The feature that you just asked for, you're not the first person to ask that. It's like, “Oh, I just want to make a tweak to this one thing. I want to edit the code. Just let me modify the code.” So we added an interactive code editor in the thing. So it's kind of moving in that direction, but I do think there's going to be some disruption to this sort of IDE space. We're already seeing it with a lot of these other editors. We're seeing it with Cursor and other integrations into VS Code. But I think we're kind of due for a rethink of what it means to be an IDE, especially in a world where we don't spend the majority of our time tweaking existing text, we spend the majority of our time refining the actual output like, “Here's the actual thing and I'm working with this.” So what does an IDE look like in that world? It's going to be really exciting.
[music plays]
BP All right, everybody. It is that time of the show. Let's shout out someone who came on Stack Overflow and shared a little knowledge. Awarded to Sodruldeen Mustapha 14 hours ago, a Lifeboat Badge for coming in and saving a question that had a negative score and giving it a great answer that's now got a score of 20 or more: “How to remove the environment variables from a Laravel Debug.” Appreciate the answer and congrats on your badge. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. Find me on X @BenPopper. If you want to come on the show and chat with us, if you want to hear us talk about something in particular, email us, podcast@stackoverflow.com. And if you enjoyed the program, the nicest thing you could do is leave us a rating and a review, or subscribe.
TO I'm Tom Occhino. You can find me on Twitter @TomOcchino. And we have our big Next.js Conf coming up very soon, so looking forward to that. Find us on socials, and thanks for the chat.
BP All right, everybody. Thanks so much for listening, and we'll talk to you soon.
[outro music plays]