The Journey of CodeSandbox Projects

Hello everyone. This is my first time that I'm speaking at ReactiveFans. 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 that I started to use Keynote for this presentation, so I'm pretty enthusiastic with animations. My name is Yves van Hoornen, 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 Yves, or Compute Yves, or it doesn't matter. Anyway, 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, but the better thing is you get the URL that you can share with other people and then they can play with that code and they can get started with, well, they can learn about your ideas. And we now have kind of a celebration. I think since yesterday, we have hit the 30 million sandboxes on Code Sandbox. And, well, that was something that when we started Code Sandbox, we never expected. Like, that was not in our wildest dreams and people have built crazy stuff. Like, for example, that Mario Kart there, that's no javascript. It's just css and it's working. You can move your kart around and everything. Anyway, during this talk, I want to talk about the story of how Code Sandbox got started. How it started as like a little student project and how it grew and grew and grew and what we've learned along the way because my goal really with this talk is to, if any of you has an idea and might want to work on that idea, I want to talk about the learnings that 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. And the first one was fine. The second one was also fine. But after the third one, I thought, okay, 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 that was really working. You were able to type code and you would see in a version. And I was so enthusiastic about this. I was thinking, wow, this is... This feels great. And that made me very motivated to, for example, add tabs. And 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, it started... I started adding npm dependency support and I started to really use this for prototyping. And until it got really to this phase where this was right before the release, I think, where it got into a version that looked very much like how it is today. And 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 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. If you have an idea, even imperfect, 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, it started to feel normal for me. So, I got demotivated to work on it. I thought, okay, 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, okay, but 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, okay, maybe there is something behind this. And with my co-founder and I, we said, okay, we are going to work on it. We're going to release it on April 1st. Every feature that is unfinished by April 1st will be dropped from the products. 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 think are great but then other people will not see the value in it. An example of this is I thought that we really needed npm registry support in Code Sandbox like that you can publish your sandbox to an npm registry so that you can use it in your local projects. Like you could build libraries on Code Sandbox. It didn't make the April 1st 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 anytime soon because, yeah, it has some merge conflicts. I don't think anyone wants to really go through those merge conflicts. But another example is for example, I thought that the way that we store files with Code Sandbox 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 they're 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. And, well, anyway. So that was also an interesting learning. Follow KISS. Keep the ideas 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 Fools. That's not really a great idea. People would just see it as a joke. So April 2nd, we released it. We had our student's 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? Like, we've worked for six months on this. We released it and no one is looking. Like, we had five registrations from people who didn't know how to code, which is great, by the way. I will get to that later. And so I started reading marketing books in panic mode. And one rule, remember, 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 sent them an email asking, hey, what do you think of Code Sandbox? And if they sent a sandbox to us, we would help them build their sandbox even. And this was an interesting opportunity because some people came back with feature requests. And the one surefire way to make someone a fan, really, is if they have a feature request and you implement that feature because it shows that you're listening to them. Now, there's this huge caveat that you should only implement features that you agree with yourself or it fits with your roadmap. 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, hmm, maybe I should try this. It shows activity. And so we started to grow. We started to get more and more users on Code Sandbox. 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 the terminal, about npm, about the code editor, about what bundler to use. Should I use react, next.js, astro? With Code Sandbox, you can go to a link 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 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 want 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, yes. 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. And the biggest one is that we, 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. And so people started to use Excalidraw locally. And 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. And 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. 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 going to show it just a couple more times because otherwise I don't do this animation justice. One more time. OK, 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. They can play with their own version that they own. However, we have integrated this with GitHub. So you can, for example, tie this 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. Ooh, a demo. So let's see. OK, so this is this Code Sandbox. And this is also what we had as a goal. Like, we, this is Code Sandbox running in 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 it makes, 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. Like, 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 integrate with this. So you can have someone working on iPad. You can have someone working 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 then 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, anything. You will directly go to a running environment with IntelliSense and everything. This is the core of what we've been building with Code Sandbox. 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 going to do the demo. We're going to continue. We're running things in the VM. And because of this, you can run anything. I mean, really anything. I have been running Minecraft with Code Sandbox, a Minecraft server on Code Sandbox and I've been connecting with it, which no one here should do this at home. Well, anyway, and you can run it with any editor. We're going to add WebStorm support and everything later as well. But the challenges with VMs, we were running things in the browser before, we were able to make that fast. But how can we make dev server start fast if we don't even know what we're running because we're running like 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 started the dev server, you work on a branch, and then you close the MacBook. Day later, you open it, the dev server is 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 Code Sandbox? Like, 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 fire. Okay. 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 in 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, then 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 Code Sandbox 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. Like, 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 we create a new branch, bloop. The big challenge here is how to make this fast. A snapshot is 8 gigabytes. How can you copy an 8-gigabyte snapshot within 2 seconds? Because that's the goal. And I can already tell you, you cannot. It was, yeah, it's a, 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. But on the blog, you can see how we enable, use Copy on Write to create snapshots really fast. But the things that this enables is really interesting. Like, 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 the 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 it can also, 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, to have Ruby on Rails, for example, Ruby on Rails 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, poof, 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 tail scale connected. This allows me to directly connect with the VM using my internal network. So I can now, ooh, the sounds also work. I'm loading in the world. Oh, it's dark. My hacks. And I can build something. Oh, that sounds just great. And I can, 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. But 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 branching concept pretty far and it's not just on, you know, 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. Ooh, 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. And thanks for listening to my talk.