The Journey of CodeSandbox Projects

Hello, everyone. This is my first time that I'm speaking at React events. I've been attending before, but now I'm speaking here and I'm very happy that I can now stand here.

I want to give a warning. This is the first time I've started to use Keynote for this presentation, so I'm pretty enthusiastic with animations.

My name is Yves Van Horne, but my name is pretty hard to pronounce, even in the Netherlands. So you can also call me Yves, you can call me Ives. My friends have trouble with my name, too. They call me Flip. If you want to call me Flip, that's fine as well. My Twitter handle is Compute Ives, or Compute Yves, it doesn't matter.

I'm here to talk about Code Sandbox. First I want to quickly check who of you know Code Sandbox? Okay, this is great. I'm still going to give a demo, because that is just something I like to do. This is Code Sandbox. Essentially, you have code and you have a preview. The great thing about it is you can make changes to that code. You will immediately see it in the preview. The better thing is you get a URL that you can share with other people and then they can play with that code and they can get started with it. Well, they can learn about your ideas.

We now have a kind of celebration. I think since yesterday we have hit the 30 million sandboxes on Code Sandbox. That was something that when we started Code Sandbox we never expected. That was not in our wildest dreams. People have built crazy stuff. All that Mario Kart there, that's not JavaScript. It's just CSS and it's working. You can move your kart around and everything. Any way, during this talk, I want to talk about the story of how Code Sandbox got started. How it started as a little student project and how it grew and grew and grew and what we have learned along the way because my goal really with this talk is if any of you has an idea and might want to work on that idea, I want to talk about the learnings we had so that you might use this as well.

And at the end, I have a bit of a technical part of the talk as well on how we make the latest version of Code Sandbox work.

So, let's go back six years and a bit. I was working at an auction website. We were converting our Ruby on Rails pages to React. And, at some point, I was on vacation to a beautiful place called St. Ives. And we went there because my name was in it. That was really the only reason. And, while I was there, I got questions from my coworkers about pieces of code. I got like snippets on Slack. I had to decipher what was going on. And I saw, well, this piece of code is not working because I think it might be this. But it was frustrating. I didn't have my laptop with me so I couldn't execute the code.

And, so, at that point, I was thinking, what if I have my development environment always available? Would that make it easier? Like, would I be able to put it in the browser, for example? And, of course, like many ideas, I didn't do anything with the idea. Instead, I started studying at the university. And at first, that was very nice. And over time, we started to get lectures. More and more lectures. And they were interesting. But then we started getting Java lectures. First one was fine. Second one was also fine. But after the third one, I thought, OK, maybe it's time to also start a side project. Maybe.

And, so, I went to my idea board. I saw Code Sandbox in there and started to open Sketch and create the first version called React Sandbox. And it was very focused on components. Like this in here. It should be a component in the...

And I thought, well, this design is done. I can start implementing. And so, we went with the implementation. This is the first version I was really working. You were able to type code and you would see the version. And I was so enthusiastic about this. I was thinking, wow, this feels great. And that made me very motivated to, for example, add tabs. You could import those tabs. And then I was thinking, well, what if you can build NPM libraries within sandboxes and then you can import them in other sandboxes?

So, this very weird dependency view came to the sidebar. But at that point, that was looking like a file explorer. So, I thought, okay. Let's make it a file explorer instead. Let's call it what it is. And then it started to get more polished. I was thinking, okay, well, this now really starts looking like a code editor. So, I started adding NPM dependency support. And I started to really use this for prototyping until it got really to this phase where this was right before the release, I think, where it got into a version that looks very much like how it is today. It's kind of like a code editor.

And the interesting part about this is that the idea started really as a component editor. And then I thought, well, what if you build component libraries in there? And what if you can share those component libraries with the world and then import them in your sandboxes? And in the end, it turns out it became an online code editor. And the main learning for me is that no matter what idea you have, it can be imperfect. It's worth working on it. And I've talked with people before where they said, well, I have this idea, but I don't think it's a good idea. So I won't work on it. But I think that's a shame, because a lot of ideas start out imperfect. And during the work on the idea, you will refine the idea and it will become better or it will be completely different. So that is incredibly important. And if you have an idea, even imperfects, start working on it. So we have this working version.

But I was looking at it every day. And I thought at some point, well, this is not interesting. It's, I mean, you can build it, you can use it to build prototypes and I was using it that way, but I was looking at it every day and it started to feel normal for me. So I got demotivated to work on it. I thought, OK, nice side project done. I'm going to, back to my lectures. And I went back to my lectures.

And then my co-students, they were asking me like, OK, what have you been doing? And I showed them, well, I've been working on this side project. It's called Code Sandbox. And I showed it to them. And they were much more enthusiastic than I was initially expecting. They were really enthusiastic about using this to start writing React code, which they haven't done much before. And I thought, OK, maybe there is something behind this. And with my co-founder and I, we said, OK, we are going to work on it, we're going to release it on April 1. Every feature that is unfinished by April 1 will be dropped from the product. And so you see this huge spike in commits. And that's what we've done.

The learning here is that, I think, you should always seek external feedback. You keep looking at your own thing and then you get a warped view of it. You get very used to that idea. But also to be able to do that release fast, because you can build huge things that you then other people will not see the value in it. An example of this is, I thought that we really needed MPM registry support in CodeSandbox, like that you can publish your sandbox to an MPM registry so that you can use it in your local projects, like you could build libraries on CodeSandbox. It didn't make the April 1 cut, and I never finished this feature. It never got merged because people were not really asking for it. And we won't merge the feature any time soon because it has some merge conflicts. But another example is, for example, I thought that the way that we store files with CodeSandbox wouldn't scale. We were storing files in Postgres in a database. And that's funny, because I thought, well, we need to really rewrite this for scale before we can ship it. And today, with these 30 million sandboxes and they all have an average of like 10 files, so 300 million files still stored in Postgres.

And today, with these 30 million sandboxes and they all have an average of like 10 files, so 300 million files still stored in Postgres. And they are still, you can update a file in about 80 milliseconds and you can retrieve a file in 10 milliseconds from Postgres. So it's, well, it's also a really good thing. Postgres is so great. Elixir as well. Well, anyway.

So that was also an interesting learning. Follow KISS. Keep the idea small. Once you've shipped it, people will give feedback and then you can use that feedback to rewrite it maybe if it's needed or to extend it with the feature set that you find valuable.

So, the big day was there. In the end, we decided not to go for April 1st because that's April Fool's. That's not really a great idea. People would just see it as a joke. So April 2nd, we released it. We had our students beer. And the tweet went out, big anticipation and we got six likes. And all those likes were from my high school friends who didn't code. So it was a bad release. And we were asking like, what do we do now? We have worked for six months on this. We released it, and no one is looking. We had five registrations from people who didn't know how to code. Which is great, by the way. I'll get to that later. And so I started reading marketing books in panic mode. And one rule I really remember, and it's that you better have 100 true fans versus 10,000 people who like you. It's better to have 100 people who really are enthusiastic about you, talk with others about what you're building, and follow you on the foot, than 10,000 people who watch you occasionally, try you occasionally. Because those 100 true fans, they will make more fans, and it will grow more organically and naturally. So we started to do the unscalable things. We started to talk directly with people.

When someone registered, we send them an email asking, hey, what do you think of CodeSandbox? And if they send us the Sandbox to us, we would help them build their Sandbox even. And this was an interesting opportunity, because some people came back with Featured Requests. And the one surefire way to make someone a fan, really, is if they have a Featured Request and you implement that Feature, because it shows that you're listening to them. There's this huge caveat that you should only implement Features that you agree with yourself, or it fits with your road map. But if you do, they will really appreciate your time.

So ship often. And if you ship, ship publicly. Share it with people, because there will be people who like you out there and they will see you constantly shipping new things and every time you ship something and you have a change log, they think, hm, maybe I should try this. It shows activity. And so we started to grow. We started to get more and more users on CodeSandbox. And that was very surreal. If you would look at my grades, it would be the inverse graph. And we got crazy, crazy feedback. Like for example, this one, marry me, I'm in love with you, this is delicious, thank you. I've included you in my will. I still need to find this person. I was so surprised by it, I made a snap of it on Snapchat, and I put behind it in Dutch. It's translating, what a feedback. I know Dutch is a challenging language.

But we also learned that people use Code Sandbox in different ways that we didn't initially know. And one big one that has been really changed how we view Code Sandbox is that people learn to code using Code Sandbox. Because if you go to Code Sandbox, you don't have to set up an environment. Imagine if you've never coded before and you have to immediately learn about a terminal, about NPM, about the code editor, about what bundler to use even. Should I use create React App? Next JS? Astro? Well, anyway. With Code Sandbox, you can go to a link and you have a running version and you can start editing the white text and you immediately get this dopamine hit of coding. What it's really about. Also learned that Code Sandbox is used to share work. We already knew this, but people use it for different types of sharing. Like, for example, job interviews or bug reports.

And people wanted to use Code Sandbox beyond prototypes. If someone started a prototype on Code Sandbox and it became bigger and bigger, the prototype would sometimes outgrow Code Sandbox. And they would have to go local. And that was a bit of a shame. We found that a shame, too. So that's incredibly... That was incredibly important for us. And we also mapped these learnings to our values in the end. Where accessibility is the biggest value. We wanted to really lower the learning curve.

But on the last one, we've been working a lot recently. And that was because Excalidraw... I'm not sure how many of you know Excalidraw. It's interesting. It's a pretty cool whiteboarding tool. And that project started on Code Sandbox. As a prototype. And it was shared on Twitter a lot of times. People also contributed... Oh, sorry. People also contributed using... To Excalidraw. And that worked for a while. But as the project got bigger, our Git integration was not as good.

The biggest one is that they saw discrepancies with their local environment. Because with Code Sandbox, we are running everything in the browser. That is challenging. Even things like... If they want to install NPM dependency for Canvas, it has C bindings. Do we now in the browser transpile those C bindings to Wasm to be able to run it? Well, there were some small discrepancies.

So people started to use Excalidraw locally. That felt like a huge loss to us. So we were thinking... Can we enable Code Sandbox for big projects? Or rather, can we enable Code Sandbox for really big projects? Can we use it to develop Code Sandbox itself? And we went to the drawing board. We asked ourselves... Can we enable the flow of Code Sandbox for any project of any size, integrated in your existing workflow? That's a mouthful. I'm not sure why I put this slide in here. But that is what we've been working on for the past, I think, one and a half years. And we call it Code Sandbox Repos. It has a lot of fancy animations. Sid helped me with this. I'm gonna show it just a couple more times because otherwise I don't do this animation justice. One more time. Okay. One more time. And then we are done.

So what is Code Sandbox Repos? It is the same flow of Code Sandbox. So you have sandboxes. You can fork those sandboxes. So you have a sandbox. People can go to it. They can fork it. And then they can do it with their own version that they own. However, we have integrated this with GitHub. So you can, for example, tie the sandbox to the main branch of your repository. When someone forks that sandbox, they get a new sandbox which is tied to a new branch of that repository. And now the cool thing about this is with GitHub, you can contribute back. So you can... Someone can create a sandbox. Someone can fork it.

And then someone can open a pull request for that sandbox. And that is very cool.

Oh. A demo. So let's see. Okay. So this is this code sandbox. And this is also what we had as a goal. This is running code sandbox. I know it is confusing. You see two editors. Here one and here one. Our team is also confused by it. It sounds very cool, but yeah, it makes for confusing parts. We're also running things like storybook in here, for example.

But I can now work with this as if I am doing development. If I want to, we have this little inspector. So I can, for example, change this. I can click on it, I go to the component name, I can change it to React. Let's make this completely React advanced-based. So go here. Also, oh, that one is already changed. I go here. Make that one also based on React advanced. Ooh, yeah, I typed. And now the editor is useless. This one at least. The other one is still working. But, yeah, everything is React advanced. Not very useful.

But this is one thing. But we also wanted you to be able to use your own code editor. So for example, you can click open in VS code. It will give me this little warning and even more warnings. Oh, no, I already had a VS code open. Two seconds. Okay. And I will now open this repository inside Code Sandbox but within my own VS code. So I can still use my own extensions and everything. I can use what I'm used to. But I have an online editor that I can share.

So for example, you can also see me twice here now. I will zoom. It's more clear. Oh. This is me. Twice. And it also has live collaboration between the different editors. So for example, I'm here in Package Station. You can see me, well, doing stuff. And the great thing about that is you can use the editor that you're used to. But if you want to quickly share something with a designer or a developer, they can use the online editor. You can still collaborate. And on top of that, we also have a native iPad app. An iPhone app. Which also integrates with this. So you can have someone working on iPad. You can have someone working in the web editor. You can have some... Yeah.

And we're going to add more integrations as well. We're opening this API up as well. So that is one very core thing. And because it's integrated with Git, you can see what changes you've made. And you can click create PR and we will handle creating the commit and everything. And also opening the PR on GitHub. That PR on GitHub will have a link to this branch as well. So that if you want to review some code, you don't have to switch your environment. You don't have to switch branches or anything. You will directly go to a running environment with IntelliSense and everything.

This is the core of what we've been building with Codesandbooks. However... Oh, yeah. This is the challenge as well. Because we are not running things anymore in the browser. We're running things in the VM. If I could... I'm not gonna do the demo. We're gonna continue. We're running things in a VM. And because of this, you can run anything. And I mean really anything. I have been running Minecraft with Codesandbooks. A server on Codesandbooks. And I've been connecting with it. Which no one here should do this at home. Well, anyway. You can run it with any editor. We're going to add WebStorm support and everything later as well. But the challenge is with VMs.

We were running things in the browser before. We were able to make that fast. But how can we make dev servers start fast if we don't even know what we're running? Because we're running this VM. And the answer is what if we don't load the dev server? Because if you work on your MacBook, you can... If you're working on a branch, you start at the dev server, you work on a branch, and you close the MacBook. A day later, you open it. The dev server still started. You don't have to wait for the dev server to start because your MacBook went to sleep in the meantime. Can we enable that for everything on CodeSandbox? Can we enable this kind of sleeping? And it's possible. It is really possible. There's something called Firecracker, which is created by AWS, Amazon. And it's a lightweight virtual machine manager. It starts VMs for you. And this is super interesting, because I can take a VM running something, I can serialize it to a snapshot disk and memory, and then I can use that. I can start new VMs from this. And the interesting thing with your MacBook, you can only snapshot like what you currently have open, right? But we can enable this for every branch. So you can be working on one branch. And you quickly open a new tab to review a PR, which is another branch, and you start it instantly. And then you can go back to your last branch that you've been working on, and you don't have to switch branches, do a yarn install, or anything. We have sleeping for every branch. And the snapshots, you can start a VM from a snapshot in 600 milliseconds. So this allows us to really create this fast experience. But you can do more. This is what I'm excited about. We have this forking model with CodeSembooks, where you can say, I fork. I go to a sandbox. I press fork. And you want an exact copy. And before this, it was a bit challenging how you would be able to do that with VMs. But with this approach, you can use that same snapshot if you want to.

What prevents me from using this snapshot to start three new VMs, for example? So what we can do is, whenever someone presses fork for the main branch, for example, we create a snapshot. Bloop! And then we copy it. Bloop! And then we create a new branch. Bloop! The big challenge here is how to make this fast. A snapshot is eight gigabytes. How can you copy an eight gigabyte snapshot within two seconds? Because that's the goal. And I can already tell you, you cannot. Yeah. We use something called Copy on Write. And I have written a blog post about this. If I would talk about this completely now, it would probably go far over time. On the blog, you can see how we use Copy on Write to create snapshots really fast. But the things that this enables is really interesting. We can do quick forks or branchable databases. Like you install a Postgres database in the main branch, you add new data to it, and then you fork that main branch. This new branch will have all that data available as well. So things like migrations, you can test it very easily on copies of databases, but also the branches will look like they are always on, because they are sleeping, and we can resume them very easily. There's no hosting cost for us. There is only storage that we have to maintain, but storage is cheap. CPU is not. And one thing that we also want to do is enable this for cloud sandboxes. Last week, we had a first release for cloud sandboxes. So that not only repos will have this kind of functionality, but we can enable sandboxes for much more than web projects. We can enable, this is just a small part, like Deno, Bun, but what if we want, for example, Ruby on rails, for example, Ruby on rail sandboxes, back to the roots, it would be possible. And that is super interesting to me. And now I want to do a very quick demo because I'm very excited about this one. I want to show you how this cloning works, this forking, by forking a Minecraft server. So I want to run a Minecraft server on code sandbox, here it is. This was, by the way, it resumed now from hibernation. So you saw this gray thing, and then it went back.

That's the resume from hibernation. So I have this Minecraft server. It's running Minecraft here. You can see the logs. And it also has a tailscale connected. This allows me to directly connect with the VM using my internal network. So I can now... Oh, the sounds also work. I'm loading in the world. Oh, it's dark. Wait. My hacks. And I can build something. Oh, that sounds just great. And we have such a simple logo. I can build our logo as a demo. Isn't that amazing?

And now I can click branch. And when we do the branch, we actually now copy the VM. We have copied this VM. And I'm still connected here. I can make changes to this one. And we also now have a new Minecraft server, which is an exact copy from the last Minecraft server I just created. And I have another Minecraft instance. I can connect to that one. And you should see that this thing is still here. So we can take this branch and go through pretty far. And it's not just on Node servers, or it's not just on web projects. It's, you can run your Docker Compose environment and have a unique instance for every branch that will start instantly. And I'm very, I'm super excited about that possibility. I never knew that that would be possible with VMs. Oh, the timer is on empty.

Okay. I want to say thank you very much for listening. I have stickers. If you have any questions, come to me and I can also give you a sticker. I have more than stickers as well.