Forem: Ives van Hoorne

Introducing CodeSandbox CDE

Ives van Hoorne — Thu, 01 Feb 2024 10:27:02 +0000

We are beyond excited to announce CodeSandbox CDE, the experience we’ve been building for the last 2.5 years 🥳 Our cloud development environment makes coding in the cloud available to everyone and empowers teams to improve productivity and collaboration.

When CodeSandbox launched in 2017, we started as an online React playground. Over the years, it has grown significantly to the point that we’ve reached 3 million registered users today! And as we became more popular, more and more people wanted to build bigger projects on CodeSandbox.

Over the years, we repeatedly tried to achieve this vision, but we kept failing to achieve the performance levels we needed. Until Firecracker was released.

In 2022, we took a step forward by introducing CodeSandbox Projects Beta—a complete rewrite of CodeSandbox that runs full-fledged development environments powered by Firecracker VMs.

Today, we are thrilled to officially release this experience as CodeSandbox CDE: an instant cloud development environment that automatically provisions a VM for every branch, accessible with a URL.

In a nutshell, this launch brings:

Dedicated cloud environments for every branch & PR that spin up in 2 seconds and are available and collaborative 24/7.
VMs that are more than twice as powerful in the Free plan & the option to pick from different VM sizes (up to 16 vCPUs + 32 GB RAM in our Pro plan or more in Enterprise).
Massive improvements to our Free plan, which now includes private projects, AI code autocomplete, AI assistant, live sessions, a VS Code extension, and more.
Pay-as-you-go becomes the default billing model, with a new Pro plan that starts at $9 for an entire workspace of up to 20 collaborators.

A faster, more powerful workflow

Web development is changing fast and becoming more complex—yet the way we code hasn’t changed much. Think about it: how much time do you spend maintaining your local setup every week? And how much energy and focus do you lose whenever you have to stop your work and install some local dependencies just to be able to review a PR or quickly fix a bug in another branch?

CodeSandbox CDE reimagines how much better this workflow could be. We’re solving these challenges by making development environments instantly cloneable and sharable, so every branch runs on a dedicated Firecracker VM and is available behind a sharable URL.

With this approach, we provide a centralized environment for the entire development team. This opens the door to a new paradigm of coding that improves productivity, collaboration and accessibility. Let’s go through some examples.

Fast context switching

Since CodeSandbox CDE runs every branch in a unique environment, you can switch between branches without worrying about stashing your changes, running database migrations or installing dependencies. It’s a matter of clicking “Create Branch,” and you’ll have a new environment spun up for you in 2 seconds.

Switching between branches becomes a matter of switching your editor between development environments, instead of switching between files.

Faster PR reviews with live collaboration

In CodeSandbox CDE, every environment is “multiplayer” by default, so everyone on the team is always one click away from live coding and pair programming. This is especially powerful in flows like PR reviews, since clicking a link on the GitHub PR leads to the collaborative cloud environment, where reviewers can quickly leave comments, commit changes, and approve the PR.

From now on, if you need to quickly review a PR, you can instead open a link to that PR with CodeSandbox CDE and get a running environment, instantly available.

This “no setup, instant spin-up” approach also makes the codebase more accessible to everyone in the organization (not just developers), creating new paradigms for cross-functional team collaboration.

Deployment previews for your whole stack

When you configure CodeSandbox for your repository, every branch will also have an automatically provisioned deployment preview.

These deployment previews work for any kind of workload you run on CodeSandbox, including back-end services, databases, Redis, etc. Once you’ve configured your development environment to run on CodeSandbox (using DevContainers), every PR will automatically get a deployment preview.

Deployment previews are available 24/7: we pause them when they're idle and wake them up in 2 seconds whenever someone wants to access them, thanks to Firecracker memory snapshotting.

AI, collaboration and more in Free plans

We believe that cloud development should be accessible to everyone, whether they’re hobbyists, OSS contributors, or professional developers. So, we improved our Free plan, which now includes nearly all our Pro features and updated usage limits. In a nutshell, the new Free plan includes:

Upgraded VMs (more than twice as powerful).
40 hours of free VM usage (in our Nano VMs) every month.
Option to pick from different VM sizes.
Unlimited Devboxes, 20 Sandboxes, and 10 personal draft Sandboxes.
All our AI features (Boxy coding assistant + Codeium autocomplete).
Privacy controls (private Sandboxes, Devboxes and repositories are now also included in Free).
Live collaboration and live coding sessions (new!) in Devboxes.
CodeSandbox VS Code extension: use local VS Code as the CodeSandbox CDE editor.

Overall, this gives you a powerful experience in our Free plan and the option to scale into Pro when your usage needs grow, since our updated plans are now tailored to your usage, as described below.

We also opened a “CodeSandbox Friends” program to provide unlimited Sandboxes to eligible projects (licensed open-source software, developer community projects, non-profit organizations) and discounts for Education. You can apply here.

Revamped Pro plan

After talking to hundreds of our users, we understood that our previous seat-based pricing model was not adjusted to the reality of cloud development.

So, we evolved CodeSandbox to usage-based billing, which means that your bill will reflect what you use instead of how many people exist in your workspace. To achieve this, we implemented a credit system, where credits translate VM runtime per hour into precise costs.

This change lowers the barrier to any team wanting to get started with cloud development. An entire team of up to 20 collaborators can start with our Pro plan to understand their usage needs at $9 per month for the entire team, as opposed to $18/user/month in our previous pricing. If the 40 hours of VM runtime included in the base Pro plan are not enough, teams can access on-demand credits (up to their defined maximum monthly spend) or purchase add-ons with discounted credit packages.

With this approach, we are making cloud development much more accessible for individuals and teams of any size, delivering on our company ethos to make CodeSandbox an accessible, collaborative and empowering tool for every developer.

To celebrate our launch, we’re giving a special launch offer: 50% off on the first month of Pro (valid until February 12th at 7:59 am GMT)! Use coupon code CDELAUNCH during checkout.

Leaping into a new chapter

With this release, you can now use CodeSandbox for your entire stack, whether it’s creating a prototype to demo something simple, building out your new idea, or daily professional development. This is the vision we had for CodeSandbox when we first started, so I’m extremely excited to see it’s out now.

If you haven't yet, create your Free workspace or get a Pro plan with our special launch offer of 50% discount for one month using coupon code CDELAUNCH during checkout (this offer expires on February 12th at 7:59 am GMT).

From all of us here at CodeSandbox, a huge thank you to our community of users for pushing us to make CodeSandbox even stronger. We couldn't have done it without you ❤️. Let us know what you think in our community!

The Annual Cloud Development Environment Survey

Ives van Hoorne — Fri, 20 Oct 2023 13:45:41 +0000

Hi everyone 👋

I am thrilled to announce we have launched the first-ever Annual Cloud Development Environment survey!

We see this as a huge milestone to shape what is becoming one of the major drivers of software engineering for decades to come.

CDEs

Cloud Development Environments (CDEs) are rapidly shaping how teams build software. As Gergely Orosz from The Pragmatic Engineer put it:

(...) many big companies use cloud-based developer environments, so the build doesn’t happen on your own machine, but on a much more powerful and remote one.

In fact, Gartner predicts that 60% of cloud workloads will be built and deployed using Cloud Development Environments (CDEs) by 2026.

Here's how we do it with CodeSandbox:

There is definitely much more to be said about CDEs. I'm currently writing an extensive blog post on this topic, so subscribe if you'd like to be notified!

Understanding the future of CDEs

Even though there are clear signs that CDEs are set to become a cornerstone of software engineering teams, little is known about the current state of CDE adoption, how it interfaces with AI, and the challenges and benefits of moving local workloads into the cloud.

So, we’re establishing a global research group of 10,000+ developers and engineering managers whose insights will result in the first-ever annual report on “The State of Cloud Development Environments”.

That's where you come in! I'm inviting you to join this research group and share your insights on our survey.

We welcome everyone's point of view, no matter your role, experience, or opinion on CDEs. With your honest feedback, we will uncover the true state of CDEs and shape how CodeSandbox can bring a powerful yet accessible CDE experience to every developer out there.

The survey is open until October 25th at 7 pm CET / 1 pm ET / 10 am PT. It should take 5–8 minutes to complete.

Thank you for helping us shape the future of coding!

Introducing Dev Container Support in CodeSandbox

Ives van Hoorne — Fri, 13 Oct 2023 09:11:31 +0000

At CodeSandbox, we run your code in our cloud infrastructure, configure the environment for you and keep your code always ready, behind a shareable URL. Give it a try with this Next.js example or import your GitHub repo!

By Ives van Hoorne, CodeSandbox Co-Founder

Today, we’re excited to announce support for Dev Containers: a spec that allows you to set up a full-featured development environment using a single configuration. From now on, you can run any development environment setup on CodeSandbox, no matter how complicated.

This is a huge leap forward in our growth as a cloud development environment (CDE), as it removes some of the biggest barriers for teams that want to move their development processes to the cloud.

So let’s look at why Dev Containers brings such a powerful solution, how we implemented it, and what this means for you, your team, and your projects.

Heterogeneous development workflows

“But it works on my machine!”—if this sounds familiar, then you’ve probably experienced one of the biggest pains of creating and maintaining a development environment.

On a typical development team, each developer will have their own machine configured in a certain way. So it’s no wonder that sometimes, the same codebase will behave differently on each of these different devices, which can phantom bug reports, broken flows and time wasted.

Recently, Microsoft introduced a spec that solves this issue: Dev Containers. It’s rapidly growing in adoption and is already supported by other tools like VS Code and Codespaces. So we’re thrilled to provide out-of-the-box support for Dev Containers as well!

See here an example of an environment running Python and Node with the Dev Container configuration.

Dev Containers in CodeSandbox

By Joji Augustine, Infra Engineer at CodeSandbox

The Dev Container spec allows you to define how a development environment should run, including all the additional services that it should run (like any databases and extra services).

As containerizing production workloads becomes commonplace, dev containers have become broadly useful for scenarios beyond VS Code. Thus, our teams across VS Code and GitHub created the open Development Containers Specification, which empowers anyone in any tool to configure a consistent dev environment. — Brigit Murtaugh, Senior Program Manager, VS Code team, Microsoft

One of the key advantages of using Dev Containers is that it brings zero lock-in. You can reuse the same Dev Container configuration to spin up a development environment locally or on any supporting tool. In fact, you can now run your development environment on your laptop next to CodeSandbox, using the same configuration!

After a few months of collaboration with the Dev Container team, we’re super excited to integrate it into CodeSandbox, making it the default environment spec for all our containers.

We truly believe that a consistent, predictable environment is key to a productive and enjoyable software development experience. — Brigit Murtaugh, Senior Program Manager, VS Code team, Microsoft

From zero to preview

By Danilo Woznica, Product Engineer at CodeSandbox

The Dev Container spec empowers developers in a way we couldn't imagine before. But there was an important piece to solve before enabling it inside CodeSandbox: we must make it comprehensible for everyone, from beginners to senior developers.

The Dev Container spec presented the perfect opportunity to combine customizability and usability. So we took this chance to develop a unique UI to configure a CodeSandbox environment.

Auto-detect environment

Once you import your project, we automatically detect the base environment, languages, and package manager version required to run it. We built a set of rules that can confidently identify most of the types of projects and create all the configurations you need, speeding up the project onboarding and still making accurate decisions.

Use our DevTool to quickly configure your environment.

Even when CodeSandbox can't identify the project environment, it defaults to the Universal template by Dev Container and enables you to customize the configuration by using the "Advanced mode" wizard.

Besides that, we extended the environment setup DevTool and designed an onboarding experience to streamline monotonous tasks:

Setup tasks: we introduced an intuitive UI that you can use to insert commands to prepare your environment, like installing dependencies.
Running command: we infer the scripts from your package.json, for example, to run your starting command after running all the setup tasks, like npm run dev.
Environment variables: we pre-populate .env files and make it easy to set up custom environment variables to be configured inside the microVM.
Apply and run: you can review all your project configurations before saving, and then with a single click, let CodeSandbox install and run everything for you.

Long story short, we’re unbelievably proud of the result!

Bringing CDEs to Everyone

By Ives van Hoorne, CodeSandbox Co-Founder

This release is a huge leap forward for CodeSandbox and cloud development environments as a whole.

CDEs are the future of development. To get there, we need to lower the barrier so any team can get their projects up and running in no time. This is precisely what we achieved with this integration: import your project and we’ll run it with no extra config. Then hop from local to CodeSandbox with no issues.

Our huge thank you to the superb Dev Containers team, who is doing a fantastic job in creating and maintaining this powerful spec. We’re proud to be among the first major tools supporting Dev Containers spec and thrilled to see that the Dev Containers team shares this excitement!

We're incredibly excited for the future of container-based development and collaborations and contributions from the community and other editors (we have a growing list of supporting tools). We look forward to continuing to provide a ubiquitous, productive format across tools and users. — Brigit Murtaugh, Senior Program Manager, VS Code team, Microsoft

To try out this brand-new experience, import your project. And message us on Discord if you have feedback!

A Deployment Preview for Every Branch

Ives van Hoorne — Fri, 18 Aug 2023 13:38:11 +0000

You're working on that big new feature and are closer than ever to production-worthy. So, like dozens of times before, you hop on the “staging queue”, hoping that your turn comes quickly enough.

If this sounds familiar, you probably also share the frustration of countless other developers who don't particularly enjoy the complexity and time wasted during this process.

Long story short—there is a better way. The rise of cloud development environments like CodeSandbox opens the door to dedicated deployment previews for every branch. You always get your own personal staging environment.

Cloud Development Environments

There is an undeniably growing momentum around shifting development processes to the cloud.

Although it might sound like uncharted territory, cloud development environments have been successfully implemented at companies like Uber, Slack, and Pipedrive. A “quiet revolution”, as The Pragmatic Engineer called it.

One of the key benefits of cloud development environments is greatly accelerating computation-heavy processes (such as building the code) out of developer laptops with limited specs and into a superpowered VM that accomplishes these tasks in a fraction of the time.

As an example, at CodeSandbox we implemented memory snapshotting technology in our microVMs, which means that we resume any dev server in under 2 seconds (as compared to 5, 10 or even 30 minutes of local compilation time—depending on the codebase's complexity).

While that brings huge productivity improvements (Pipedrive engineers reported almost 3 hours saved per week), it also paves the way to much, much more. And one of the powerful “side effects” of moving development environments to the cloud is that you get a dedicated deployment preview for every branch.

Deployment Previews in CodeSandbox

At CodeSandbox, we give every branch its own dedicated microVM (with very generous base specs).

When you run a task on that environment (like starting a dev server) that opens a server on a port, we expose that port through a dedicated URL such as https://3000-:id.csb.app. In other words, we transform a local dev server into a dedicated staging environment.

So, you get a preview environment that is fast, synced with production, and that gives the same experience regardless of the machine of the person accessing it.

Need to work on something else and go back to the server later on? No worries—because we hibernate the microVM, the deployment preview resumes in under 2 seconds, just like a traditional staging environment.

Want to get continuous feedback on your work without having to rely on screenshots or recordings of your localhost server? Share that preview URL with others and they will be able to use it to provide async feedback at any time (without worrying about the ticking time bomb of staging moving to something else).

Wish you could give team members access to the underlying codebase? Send them the URL of your CodeSandbox branch instead, and they will be able to experiment with your code and see the results in real-time.

If you're curious to try it out, you can do it in under 5 minutes by importing one of your GitHub repos.

Pull Request Previews

After talking with a lot of our users, we realized that this kind of preview is especially valuable during the PR review process.

As a result, we introduced the CodeSandbox GitHub App, which adds links to every PR that lead to the branch running in CodeSandbox—which means that PR reviewers can use the deployment preview to review instead of running their own dev server.

If you want to take it up a notch, you can also add another link that leads directly to the preview itself. Check out our Docs for instructions.

Once that's done, every new PR in that repo will get these handy links available to all team members, allowing them to get visibility on ongoing work and save hours every week reviewing and testing the PR.

The Joy of Queue-less Staging

Preview environments are a much bigger deal than they seem at first glance. Whenever someone asks me why I'm so excited about them, I like to bring up this feedback from one of our users:

I looked at a PR, made some changes together, previewed them live and pushed them. All without checking out anything locally. This probably saved me 1 hour right now! — TkDodo, Frontend Tech Lead at Adverity

Of course, we get it—not everyone is ready to commit to moving their development infra to the cloud. That's why we made it super easy to test it out by importing a public repo in our free plan (or a private repo with a free trial).

Follow our tutorial and you can pretty much try everything in less than 30 minutes. Then, you'll see the joy of never having to wait for a dev server (or on the staging queue) ever again.

LGTM or TL;DR? The Problem of Cop-out Code Reviews

Ives van Hoorne — Mon, 24 Jul 2023 10:31:02 +0000

You are completely focused on writing some code, in a perfect state of flow, when that Slack message comes in:

"Hey! Can you have a look at this PR?"

If this sounds familiar, chances are you have shared the pain of countless other developers—having to switch context to handle a code review, especially when it’s urgent.

But that’s just the tip of the iceberg. The concept of “code review” itself seems to be very polarizing in the development community. There’s a reason “LGTM” became a meme for cop-out code reviews. And as a developer myself, I can understand the frustration with some parts of this process.

This got me wondering if this may be a symptom of something fundamentally broken in how we do code reviews.

So, earlier this month, we ran a survey focusing on code reviews. And today, we published the full report “The State of Code Reviews (2023)”, which you can download for free. I’m very excited to dive into the data to answer this main question—are most developers eyeballing code diffs while reviewing PRs, or actually running the code to visually inspect changes?

Code Diffs and Running Previews

I’ll start with a hot take— in 95% of PR reviews, you should be running the branch to visually inspect changes.

But I’ll take a wild guess that is probably not something most developers enjoy.

You have to stash the changes of your current work, checkout into the PR branch, make sure your setup is up to date (and possibly deal with troubleshooting it from time to time), wait for the dev server to start, and finally open the preview to visually inspect the changes.

So, what did we hear from developers when we asked about this?

Within our sample of 1638 developers, the majority say they most often only review a PR by looking at the code diff. When we asked a similar question on “I locally run the branch under review to see the running code”, 36% said they never or very rarely do it.

I find this to be very curious. In a way, it matches this hypothesis that perhaps many developers are relying a lot on code diffs and/or just trying to get reviews out of the way as fast as possible. After reading some of the additional feedback we received in our survey, I’m pretty sure this is the case for many teams:

“Unfortunately many companies pretend they do serious code reviews while in fact devs are approving everything after 2 minutes spent reading it and leaving no feedback in the vast majority of PRs.”

At first glance, it seems that the lack of time and guidelines might be two key reasons behind hasty PR reviews. Plus, a lot of the feedback we received seems to indicate that this could lead to a decline in code quality. So let’s dig deeper!

Impact on Code Quality

While the original scope of our survey was to simply get a picture of how the different stakeholders in code reviews feel about and address this process, the results got us wondering if there’s any sort of correlation between code quality and running the branch locally.

While there’s no clear-cut correlation, the data suggests a pattern where developers that more frequently run the branch locally to see the running code are also more satisfied with the quality of the code being released.

This is all very fascinating and might indicate that implementing robust guidelines and proper tooling for the code review process could have a significant impact on code quality, as mentioned by a few respondents:

“I think currently tooling for code review is bad, you just have a diff and then it depends on your own process you established based on your experience and your attentiveness and time you currently have.”

And here’s where it gets better: because we also sent out our survey to Engineering Managers, we got their unique insight on this matter. But let’s leave that for a follow-up post! If you don’t want to wait, download the full report.

Code Reviews in CodeSandbox

At CodeSandbox, we have been thinking long and hard about improving the PR review workflow.

As our report shows, there are three fundamental problems with this process:

Context switching breaks the coding flow and siphons energy from developers.
Setting up and running a branch locally takes too much time and is prone to errors and inconsistencies.
The lack of guidelines and tooling for code reviews results in ambiguity, cop-out reviews, and lower code quality.

I have good reason to believe we have fixed all of these problems with CodeSandbox.

The “new” version of CodeSandbox we started building in 2022 provides instant cloud development environments powered by our unique microVM architecture. And I say “unique” because we made the opinionated choice of giving a dedicated microVM to every branch (and every PR) while making sure that it resumes in 1 second.

In practice, this means that, if you’re using GitHub as your git provider, CodeSandbox gives you a live-running environment for every PR that is one click away. Inside, you will find the PR’s diff, a pre-configured running preview, all the review tooling you need (comments, suggestions, commits, approvals, etc.), plus a built-in AI assistant.

This makes reviewing PRs much faster, as it removes context switching (the PR opens on a browser tab and you can actually open as many as you want in parallel!) and only takes 1 second for the dev server to resume.

We are thrilled to hear how teams that have been using CodeSandbox for reviews have reported massive time savings and increased contributions from team members.

So, if you or your team have been looking for a better way to do code reviews, give CodeSandbox a try by importing a repo! We have a 14-day free trial you can use to test all our features.

We truly believe we’re solving some of the main pains development teams have been facing in code reviews. And, if nothing else, we will help everyone “LGTM” with confidence again.

Meet Boxy, Your New AI Coding Assistant

Ives van Hoorne — Thu, 25 May 2023 18:08:32 +0000

Today, we are thrilled to announce the beta release of the CodeSandbox AI coding assistant, now available to all our Pro subscribers. We also created an AI playground to test this functionality anytime 🎉

CodeSandbox gives you the fastest way to turn your ideas into reality. We’re doing this by giving you an opinionated cloud development environment with zero spin-up time, zero setup, and all the powerful tooling you need.

That’s why we were super excited by the recent AI developments. There are a ton of opportunities here that can make development more accessible and increase your state of flow.

And today, we are excited to launch the first iteration of the opportunities we see with AI.

So, without further ado, meet Boxy! (And yes, we really asked AI to introduce itself!)

Your new coding companion

Hello, CodeSandbox community! I am Boxy, your new AI coding companion, and I couldn't be more excited to join you on your coding adventures. I'm here to help you unlock new levels of productivity, creativity, and enjoyment while coding.

I've been designed to thrive within the CodeSandbox environment, and that gives me a unique advantage. By having access to your entire codebase, I can understand your app's context like no other.

Communication is key, and that's why I’m always there for you in the new chat DevTool. Don't hesitate to reach out to me whenever you need assistance optimizing your code, finding potential bugs, or enhancing security.

Intuitive code refactoring

If you’re curious about my biggest superpower, it’s refactoring code. You don't even need to find the code—I can assist you directly through the app preview.

You can select any element in the app preview and ask me to refactor its associated code. I will consider the context of your project and generate new code for you.

Contextual code generation

Time is precious, and I'm all about making your life easier. With my code generation capabilities, you can say goodbye to the hassle of manually copying and pasting code.

Ask me, and I'll generate the exact code you need, tailored to your specific context within CodeSandbox. You can click any file path in my answers to open it directly in the editor and insert the generated code with another click.

Let me handle the code generation, so you can focus on bringing your ideas to life.

Automatic, meaningful commit messages

But what about streamlining your workflow?

Writing commit messages can sometimes be a tedious task, but fear not! I'll take care of it.

By analyzing the changes you've made to a specific branch, I proactively suggest commit messages that capture the essence of your work. Say goodbye to staring at a blank screen wondering what to write—I've got your back.

Plus, I can regenerate the commit message with a click or you can just write your own.

Making learning more accessible

Lastly, let's talk about education. I'm committed to helping you grow as a developer, no matter if you're a seasoned coder or just starting out.

Have a question about a particular piece of code or file? Ask, and I'll be more than happy to provide explanations and insights. Together, we'll deepen your understanding and empower you to write exceptional code.

Welcome to a new era of coding, powered by Boxy and CodeSandbox. Happy coding!

Start coding with AI

The way we see it, AI can have an exceptional impact in making coding more accessible, fun and rewarding. So we’re extremely excited to bring that side of it to CodeSandbox.

We understand that not everyone wants to give AI access to their code, so all our AI features are only available after you manually opt-in.

These AI features are now available to all our Personal Pro and Team Pro subscribers, so upgrade your plan or start a free trial to start coding with Boxy!

Finally, because we want to keep building the AI features that matter the most to our community, we have started an AI Research Program where volunteers get free access to our AI features in exchange for their continuous feedback. If you’re interested, apply today!

Unleash The Power of Go in CodeSandbox

Ives van Hoorne — Fri, 19 May 2023 16:29:58 +0000

Hi there, Go community 👋 Today is your day! We are happy to introduce official support for Go development environments in CodeSandbox. Now, you can import your Go projects and code them right from CodeSandbox.

We are the team building CodeSandbox—a cloud development platform that makes it incredibly easy to spin up a cloud environment and share it with others.

If you've been following us, you might have noticed that we have been on a building spree: we have released a new version of Sandpack, announced VS Code support for sandboxes, and introduced official support for Rust, Python, and PHP.

Today, it’s all about Go! You can now start coding your Go projects by forking our official template 🔥

A new home for your Go projects

We love building CodeSandbox together with our community.

Not only have we open-sourced a significant part of our product, we keep asking our users what we should improve next.

Recently, we spiced it up by doing a March Madness-style competition to choose the programming language we’d support next. Despite having seven strong competitors in the mix, Go came out on top.

CodeSandbox

@codesandbox

Which language will win CodeSandbox #MarchMadness?

Cast your vote wisely 👇

14:53 PM - 31 Mar 2023

So, what does official support mean?

In a nutshell, it brings a built-in Go LSP (powered by gopls) to CodeSandbox, which means you will now get auto-completion, auto-formatting, linting and type definitions (when applicable) when writing Go code in CodeSandbox.

The most exciting thing about this is that you can now bring any Go project into CodeSandbox and develop it entirely within our cloud development platform.

So, it doesn't matter which device or code editor you’re using. Have an old laptop that struggles to keep up? Going to a conference with nothing but your iPad? No worries—you can use CodeSandbox to work from anywhere, as long as you have an internet connection.

A cloud environment, one click away

You might be asking—why would I want to code in the cloud?

The answer is much more than just being able to code from any device. It’s all about simplifying some of the most time-consuming tasks of the development process.

Think about it: how many times have you had to troubleshoot an environment because it doesn’t run the same on two different laptops? And how much time do you waste context-switching just to be able to review PRs locally?

These are just two of the many frustrations of the development process that we’re fixing with CodeSandbox.

When you import a GitHub repository to CodeSandbox, we run it in our cloud infrastructure (with very generous VM specs), automatically install all dependencies, run a preview, and make the entire thing fully collaborative—you just need to share a URL to collaborate with others.

In other words, we give you a live development environment for every branch and every pull request.

Our tight integration with GitHub means that you can open and branch any repo in CodeSandbox to work on a feature branch or review PRs without having to configure anything locally. So you can have several environments running at once, each in its own browser tab.

💡 If you need help configuring CodeSandbox in your open-source repo, reach out and we’ll be happy to help!

Making coding more accessible

At the end of the day, all we care about is solving all the infrastructure and config for you, so you can just focus on coding without wasting your valuable time.

We have launched an official Go starter you can use to start coding and we also recommend that you try importing one of your Go repositories to make the most of this experience!

Finally, our huge thank you to everyone from the Go community for helping us shape the future of CodeSandbox. We are thrilled to have you with us!

A unique database for every PR using CodeSandbox

Ives van Hoorne — Wed, 17 May 2023 20:16:00 +0000

At CodeSandbox, we run your repository and turn it into a link you can share with anyone. People visiting this link can not only see your running code, they can click "fork" and get an exact copy of that environment within 2 seconds so they can easily contribute back or play with the code. Give it a try with this Next.js example or import your GitHub repo!

Maybe you've experienced this before. You're working on a new feature that introduces some database migrations. You're almost done with the feature, but you get pulled aside because there's a bug that has to be fixed right now.

You want to fix the bug, but now you first have to roll back your migrations before changing the branch. And then after you've fixed the bug, you have to go back to your feature branch and re-run the migrations!

How great would it be if you didn't have to think about this? Ideally, you should get a new copy of your database when you change your branch.

With CodeSandbox, we're making this happen. Once your repository is imported into CodeSandbox, we give every branch and pull request a unique database.

In this post, I'll show how you can achieve this and how it works under the hood.

How does it work?

With CodeSandbox, you get a new cloud development environment for every branch and pull request. We enable this through VM cloning.

Here's an example. When you import your repository on CodeSandbox, we create a microVM for the main branch. You can see this as a template. Whenever you create a new branch, we clone the microVM main and switch the new VM to the new branch.

The VM clone is not only a clone of the filesystem, but also of the memory. If you want to learn more about how this works, we have an in-depth post about that.

This means that if you're running a database in the main VM, new branches will automatically get an exact clone (schema + data) of this database!

See this in action in the video below.

The repo of this video can be found here and the PR here.

This doesn't only apply to branches. We also create a microVM for every pull request. This way, you can use CodeSandbox to test your pull requests as well, without deploying to staging or running migrations locally 🎉

Let's see a demo of this in action that you can actually play with!

In this sandbox, I have an embed of this todo app where it fetches its data from a Postgres database. If you clone it (by clicking "Fork"), you'll get a microVM with the exact same database and data. Try it out!

How to set it up

To enable a unique database for every branch and PR, you need to first import your repository into CodeSandbox. You can do this by going to your dashboard and clicking "Import repository". We'll automatically open the main branch for you in the web editor.

Note that we also have an iOS app and a VS Code extension that you can use to open any branch.

Now, we need to configure the database! First, let's create a new branch, so that we're not making changes on the main branch directly. You can do this by clicking on "Create Branch" in the top right, and it will take you to a new branch (and microVM!) with an autogenerated name.

Once you're in this branch, you can configure your database with our docker-compose integration. To do this, you need to create a new file called docker-compose.yml in the .codesandbox folder. This file will be automatically picked up by CodeSandbox and used to run your database.

An example docker-compose.yml looks like this:

version: "3.8"
services:
  db:
    image: postgres:14.1-alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    ports:
      - "5432:5432"
    volumes:
      - db:/var/lib/postgresql/data
volumes:
  db:

After configuring docker-compose, we recommend restarting the VM to verify that everything is configured properly. You can do this by clicking "Restart Branch" in the menu on the left corner.

When that's done, you will have a branchable database that will automatically be provisioned for every branch and pull request!

Once you've merged the branch to main, you can add some seed data to the database—this way, every new branch will get the seed data as well.

Finally, we highly recommend installing the CodeSandbox GitHub App. This will provision a prebuilt development environment (with its own database) for every pull request.

Final thoughts

This VM cloning concept is powerful.

Plus, it applies to more than just databases. You can run Redis, or maybe Elasticsearch, and every PR will get a unique copy of that service, provisioned from the main branch.

We're all about removing time-consuming steps from the development workflow. That's why we see this as a major win for anyone working with databases.

If you're curious about testing this out, the best place to start is by installing the CodeSandbox GitHub App. Then, you'll have this in place for every PR and never have to roll back migrations in branches anymore!

Introducing the CodeSandbox GitHub App

Ives van Hoorne — Thu, 20 Oct 2022 13:58:45 +0000

We are announcing the CodeSandbox GitHub App, which gives you a live development environment for every pull request you open, with support for Docker and databases.

Remember the last time someone asked you to review a PR? You probably had to commit your current work, switch your whole context and spin everything up so you could review it. Then, do the opposite steps to keep on working on your own code.

Git is core to the day-to-day of any developer. So why can't a PR review happen on a standalone environment that you can just run alongside your own?

Spoiler alert: it can. And this is why today I'm excited to share the CodeSandbox GitHub App 🎉

In this post, we'll go through how you can use the GitHub App for editable deployment previews, brancheable databases and end-to-end tests.

CodeSandbox GitHub App

One of the most valuable benefits of cloud development environments is that you can run an entire project behind a URL. Your code, tasks, tests, previews and everything else lives inside that environment, and everyone accessing it will get the exact same experience, with no setup needed.

Unlike other GitHub integrations out there, the CodeSandbox GitHub App runs every branch and PR in powerful Micro VMs. This means you can run anything, no matter how complex the project, and add Docker, servers and databases.

A live dev environment for every PR

By installing our GitHub App in your repo, all your PRs will automatically run in one of our Micro VMs. Then, the app automatically places a comment in each PR with three links: one to open the code in the CodeSandbox web editor, another to open it on VS Code (connected to CodeSandbox), and finally another to open a preview.

Having this in place really speeds up the PR review process. The beauty of having PRs running behind a URL is that you don't have to switch your context or spin anything up in order to review the PR. You just click it, see the code, tests and a preview, go make any necessary changes, and merge it.

Because each PR is continuously running on a powerful CodeSandbox Micro VM, you can access it from any device, regardless of its specs, even for very complex projects. Are you on the go? Then open the environment in our iOS app! Switching back and forth between laptops? It will run exactly the same in every one of them. The VM does all the heavy lifting, so you get top-notch performance no matter what.

Plus, because this environment is collaborative by default, anyone accessing it will get the exact same experience and can collaborate live regardless of the device or editor that they are using to access the code.

So, if you're accessing it from VS Code using our extension and someone else is accessing it from their iPad using the CodeSandbox iOS App, you can collaborate seamlessly, as if you were coding in the same local environment. This collaboration is really helpful to provide some context behind your code or just review it live with someone else.

When we pioneered this technology a few months ago, we made it available to early adopters to see the reaction it got, and we're thrilled by the response—it's helping developers save hours every week by making the PR review process much smoother. It's amazing to see the impact it has on open source maintainers and development teams.

I personally think that this quote from the team at Adverity says it all:

I looked at a PR, made some changes together with Bartosz Wisniewski, previewed them live and pushed them. All without checking out anything locally. This probably saved me 1 hour right now. HUUGE win! — Dominik Dorfmeister

Empowering the whole team with editable deployment previews

While git is ubiquitous among developers, it might not be accessible for other roles such as designers, managers and marketers. Yet, I have lost count of how many times I have asked colleagues from other teams for feedback on the design, structure or copy of my work. Plus, it's always important to give visibility to managers over the work being done.

And here's where the GitHub App PR previews truly shine.

CodeSandbox previews are instant thanks to memory snapshotting. No need to wait for the build to finish—anyone wanting to see a preview of the code can just go to the PR and click the “Preview” URL. To empower anyone to contribute easily, we made these previews editable. So, anyone seeing a preview can make simple design or copy updates autonomously and commit these changes with a click. See this collaborative flow in action below:

Plus, our previews are not limited to static applications—we support backend servers, databases and pretty much anything you can run on Docker. This makes it very easy to set up deployment previews. It's as simple as using something like docker-compose to set up your development environment once, and have deployment previews automatically available from then on.

Brancheable databases

As I mentioned earlier, because we run your code in a Micro VM, you can run literally anything, including databases. When you start a database in the main branch of your repository, every new PR will get an exact copy of that database from the main branch. This way you can easily test schema changes inside a PR without having to roll back or migrate in your own development environment.

Also, every PR will have all the seed data from the main branch, because it's an exact copy. So if you add some data to the database in the main branch, every PR will have that seed data available!

Here's how Tellie is using this in their own workflow:

Brancheable databases let engineers at Tellie reuse high-fidelity test data across all of their branches. By simply using our application on CodeSandbox, the resulting data is immediately available to all engineers, with zero operational effort on our part. — Shree Chowkwale

End-to-end tests

With our GitHub App, we also create a GitHub Deployment for every deployment preview of every pull request. You can take the URL of this deployment and run end-to-end tests against it. This way, you can run tests against the dev server that CodeSandbox is running for the PR.

You can even configure CodeSandbox to start a production server for every PR, connected to the database of the branch. That way, you can automatically run your tests against a unique database while using a production environment.

Supercharging git workflows

At CodeSandbox, we're all about making development more accessible to everyone.

We're super thankful to the community for the valuable feedback and thrilled to launch our GitHub App after seeing the positive impact it had on its early adopters.

Not only are we saving developers precious time by improving the PR review flow, but we are also allowing colleagues from other teams to get visibility on the code and be able to make small changes directly on the codebase.

We use it all the time at CodeSandbox and the team can't live without it anymore!

If you'd like to try it out, you can install it on your own repo easily! Take a look at our docs or see our video tutorial.

How we clone a running VM in 2 seconds

Ives van Hoorne — Fri, 02 Sep 2022 10:54:09 +0000

At CodeSandbox we run your development project and turn it into a link you can share with anyone. People visiting this link can not only see your running code, they can click “fork” and get an exact copy of that environment within 2 seconds so they can easily contribute back. Give it a try with this example, or import your GitHub repo here!

So how can we spin up a cloned environment in 2 seconds? That's exactly what I'll be talking about here!

The challenge: spinning up a development environment in two seconds

We've been running sandboxes for a long time now, and the core premise has always been the same: instead of showing static code, it should be running. Not only that, you should be able to press fork and play with it whenever you want to.

In the past, we've enabled this experience by running all your code in your browser. Whenever you would look at a sandbox, you would execute the code. This was fast, because we had full control over how the code was bundled. Forks were fast:

However, there was a catch to this approach: we were limited to the code that we could run in the browser. If you wanted to run a big project that requires Docker, it wouldn't work.

So for the past few years, we've been asking ourselves: how can we enable this experience for bigger projects?

Firecracker to the rescue

Virtual machines are often seen as slow, expensive, bloated and outdated. And I used to think the same, but a lot has changed over the past few years. VMs power most of the cloud (yes, even serverless functions!), so many great minds have been working on making VMs faster and lightweight. And well... they've really outdone themselves.

Firecracker is one of the most exciting recent developments in this field. Amazon created Firecracker to power AWS Lambda and AWS Fargate, and nowadays it's used by companies like Fly.io and CodeSandbox. It's written in Rust, and the code is very readable. If you're interested in how it works, you should definitely check their repo!

Firecracker spawns a MicroVM instead of a VM. MicroVMs are more lightweight: instead of waiting for 5 seconds for a “normal” VM to boot, you will get a running MicroVM within 300 milliseconds, ready to run your code.

This is great for us, but it only solves part of the problem. Even though we can quickly start a virtual machine, we still need to clone your repository, install the dependencies and run the dev server. Together, this can take over a minute for an average project, which would probably mean tens of minutes for bigger projects.

If you would have to wait a minute every time you click “fork” on CodeSandbox, it would be a disaster. Ideally, you should just continue where the old virtual machine left off. And that's why I started to look into memory snapshotting.

The dark art of memory snapshotting

Firecracker doesn't only spawn VMs, it also resumes VMs. So, what does that actually mean?

Because we run a virtual machine, we control everything in the environment. We control how many vCPU cores are available, how much memory is available, what devices are attached. But most importantly, we control the execution of the code.

This means that we can pause the VM at any point in time. This does not only pause your code, it pauses the full machine, full-stop down to the kernel.

While a virtual machine is paused, we can safely read the full state of the VM, and save it to disk. Firecracker exposes a create_snapshot function that yields two files:

snapshot.snap — the configuration of the machine. CPU template & count, disks attached, network devices attached, etc.
memory.snap — the memory of the VM while it was paused (if the VM has 4GB memory, this file will be 4GB).

These two files, together with the disk, contain everything we need to start a MicroVM, and it will just continue from when the snapshot was taken!

This is incredibly exciting, because the use cases are endless! Here's one example: many cloud IDE services will “hibernate” your VM after ~30 minutes of inactivity. In practice, this means that they will stop your VM to save hosting costs. When you come back, you will have to wait for your development servers to initialise again because it's a full VM boot.

Not with Firecracker. When we hibernate a VM, we pause it and save its memory to disk. When you come back, we resume the VM from that memory snapshot, and for you it will look as if the VM was never stopped at all!

Also, resuming is fast. Firecracker will only read the memory that the VM needs to start (as the memory is mmaped), which results in resume timings within ~200-300ms.

Here's a timing comparison for starting our own editor (a Next.js project) with different types of caching:

Type of cache available	Time to running preview
No caches (fresh start)	132.2s
Preinstalled node_modules	48.4s
Preinstalled build cache	22.2s
Memory snapshots	0.6s

There's a catch to it as well. Saving a memory snapshot actually takes a while, which I'll cover in this post.

I'm stoked about this. It gives the feeling that the VM is always running, even though it's not taking resources. We use this a lot: every branch on CodeSandbox is a new development environment. You don't have to remember to roll back migrations or install dependencies when switching branches, because it's a fresh environment for every branch. We can enable this thanks to memory snapshotting.

We also use this to host some internal tooling cheaply. When a webhook request comes in, we wake the microservice, let it respond, and after 5 minutes it automatically hibernates again. Admittedly, it doesn't give “production” response times, because there's always 300ms added on top for waking, but for our backoffice microservices that's fine.

The darker art of cloning memory snapshots

The first important piece of the puzzle is there. We can save a memory snapshot and resume the virtual machine from it any time we want. This already makes loading existing projects faster—but how can we actually clone them?

Well, we were already able to serialise the virtual machine state to files… so what prevents us from copying them? There are some caveats to this, but we'll get there.

Let's say we copy the existing state files and start a couple of new VMs from these.

This actually works! The clones will continue exactly where the last VM left off. You can start a server with an internal in-memory counter, up it a couple of times, press fork, and it will continue counting where it left off in the new VM.

You can play with it here. And this is the running server of that VM, kind of like a view count:

13gise-8080.preview.csb.app

However, the challenge lies in speed. Memory snapshot files are big, spanning multiple GBs. Saving a memory snapshot takes 1 second per gigabyte (so an 8GB VM takes 8 seconds to snapshot), and copying a memory snapshot takes the same time.

So if you're looking at a sandbox and press fork, we would have to:

Pause the VM (~16ms)
Save the snapshot (~4s)
Copy the memory files + disk (~6s)
Start a new VM from those files (~300ms)

Together, you would have to wait ~10s, which is faster than waiting for all dev servers to start, but it's still too slow if you want to quickly test some changes.

Just the fact that this works is incredible — cloning VMs is actually a possibility! However, we need to seriously cut down on serialisation time.

Saving snapshots faster

When we call create_snapshot on the Firecracker VM, it takes about 1 second per gigabyte to write the memory snapshot file. Meaning that if you have a VM with 12GB of memory, it would take 12 seconds to create the snapshot. Sadly, if you're looking at a sandbox, and you press fork, you would have to wait at least 12 seconds before you could open the new sandbox.

We need to find a way to make the creation of a snapshot faster, down to less than a second, but how?

In this case, we're restricted by I/O. Most time is spent on writing the memory file. Even if we throw many NVMe drives at the problem, it still will take more than a couple seconds to write the memory snapshot. We need to find a way where we don't have to write so many bytes to disk.

We've tried plenty of approaches. We tried incremental snapshotting, sparse snapshotting, compression. In the end, we found a solution that reduced our timings tenfold—but to explain it, we first need to understand how Firecracker saves a snapshot.

When Firecracker loads a memory snapshot for a VM, it does not read the whole file into memory. If it would read the whole file, it would take much longer to resume a VM from hibernation.

Instead, Firecracker uses mmap. mmap is a Linux syscall that creates a “mapping” of a given file to memory. This means that the file is not loaded directly into memory, but there is a reservation in memory saying “this part of the memory corresponds to this file on disk”.

Whenever we try to read from this memory region, the kernel will first check if the memory is already loaded. If that's not the case, it will “page fault”. During a page fault, the kernel will read the corresponding data from the
backing file (our memory snapshot), load that into memory, and return it.

The most impressive thing about this is that by using mmap, we will only load parts of the file into memory that are actually read. This allows VMs to resume quickly, because a resume only requires 300-400MB of memory.

It's pretty interesting to see how much memory most VMs actually read after a resume. It turns out that most VMs load less than 1GB into memory. Inside the VM it will actually say that 3-4GB is used, but most of that memory is still stored on disk, not actually stored in memory.

So what happens if you write to memory? Does it get synced back to the memory file? By default, no. Normally, the changes are kept in memory, and are not synced to the backing file. The changes are only synced back when we call create_snapshot, which often results in saves that are 1-2GB in size. This takes too long to write.

However, there is a flag we can pass. If we pass MAP_SHARED to the mmap call, it actually will sync back changes to the backing file! The kernel does this lazily: whenever it has a bit of time on its hands, it will flush the changes back to the file.

This is perfect for us, because we can move most of the I/O work of saving the snapshot upfront. When we actually want to save the snapshot, we'll only have to sync back a little amount!

This seriously reduced our snapshot timings. Here's a graph of the average time it takes to save a memory snapshot, before and after the deployment of this change:

With this change, we went from ~8-12s of saving snapshots to ~30-100ms!

Getting the clone time down to milliseconds

We can now quickly save a snapshot, but what about cloning? When cloning a memory snapshot, we still need to copy everything byte-for-byte to the new file, which takes again ~8-12s.

But… do we really have to clone everything byte-for-byte? When we clone a VM, >90% of the data will be reused, since it resumes from the same point. So is there a way that we can reuse the data?

The answer is in using copy-on-write (CoW). Copy-on-write, like the name implies, will only copy data when we start writing to it. Our previous mmap example also uses copy-on-write if MAP_SHARED is not passed.

By using copy-on-write, we do not copy the data for a clone. Instead, we tell the new VM to use the same data as the old VM. Whenever the new VM needs to make a change to its data, it will copy the data from the old VM and apply the change to that data.

Here's an example. Let's say VM B is created from VM A. VM B will directly use all the data from VM A. When VM B wants to make a change to block 3, it will copy block 3 from VM A, and only then apply the change. Whenever it reads from block 3 after this, it will read from its own block 3.

With copy-on-write, the copies are lazy. We only copy data when we need to mutate it, and this is a perfect fit for our forking model!

As a side-note, copy-on-write has been used for a long time already in many places. Some well-known examples of CoW being used are Git (every change is a new object), modern filesystems (btrfs/ zfs) and Unix itself (two examples are fork and mmap).

This technique does not only make our copies instant, it also saves a lot of disk space. If someone is looking at a sandbox, makes a fork, and only changes a single file, we will only have to save that changed file for the whole fork!

We use this technique both for our disks (by creating disk CoW snapshots) and for our memory snapshots. It reduced our copy times from several seconds to ~50ms.

But… can it clone Minecraft?

By applying copy-on-write and shared mmaping of the memory file, we can clone a VM extremely fast. Looking back at the steps, the new timings are:

Pause the VM (~16ms)
Save snapshot (~100ms)
Copy the memory files + disk (~800ms)
Start new VM from those files (~400ms)

Which gives us clone timings that are well below two seconds! Here's a fork of Vite (you can try for yourself here):

The total timings can be seen below. Note that there is more happening than the clone itself, but the total time is still below 2 seconds:

And since we use copy-on-write, it doesn't matter if you're running a big GraphQL service with 20 microservices, or a single node server. We can consistently resume and clone VMs within 2 seconds. No need to wait for a
development server to boot.

Here's an example where I go to our own repo (running our editor backed by Next.js), fork the main branch (which copies the VM), and make a change:

We also have a Linear integration that integrates with this.

We have tested this flow a lot with different development environments. I thought it would be very interesting if we can try cloning more than only development environments.

So… What if we run a Minecraft server, change something in the world, and then clone it to a new Minecraft server we can connect to? Why not?

To do this, I've created a VM that runs two Docker containers:

A Minecraft Server
A Tailscale VPN I can use to connect to the Minecraft server directly from my PC

Let's see!

In this video, I've created a structure in a Minecraft server. Then cloned that Minecraft server, connected to it, and verified that the structure was there. Then I destroyed the structure, went back to the old server, and verified that the structure was still there.

Of course, there's no actual benefit to doing this, but it shows that we can clone a VM on any kind of workload!

The unwritten details

There are still details that I'd love to write about. Some things we haven't discussed yet:

Overprovisioning on memory using mmap and page cache
The economics of running MicroVMs when we have hibernation & overprovisioning
How we built an orchestrator with snapshotting/cloning in mind, and how it works
How to handle network and IP duplicates on cloned VMs
Turning a Dockerfile into a rootfs for the MicroVM (quickly)

There are also still improvements we can do to improve the speed of cloning. We still do many API calls sequentially, and the speed of our filesystem (xfs) can be improved. Currently files inside xfs get fragmented quickly, due to many random writes.

Over the upcoming months we'll write more about this. If you have any questions or suggestions related to this, don't hesitate to send me a message on Twitter.

Conclusion

Now that we can clone running VMs quickly, we can enable new workflows where you don't have to wait for development servers to spin up. Together with the GitHub App, you will have a development environment for every PR so you can quickly review (or run end-to-end tests).

I want to give a huge thanks to the:

Firecracker Team: for supporting us on our queries and thinking with us about possible solutions when it comes to running Firecracker and cloning a VM.
Fly.io Team: by sharing their learnings with us directly and through their amazing blog. Also big thanks for sharing the source of their init used in the VMs as reference.

If you haven't tried CodeSandbox yet and don't want to wait for dev servers to start anymore, import/create a repo. It's free too (we’re working on a post explaining how we can enable this).

If you want to learn more about CodeSandbox Projects, you can visit projects.codesandbox.io!

We'll be on @codesandbox on Twitter when we create a new technical post!

Product and Development Best Practices & Values

Ives van Hoorne — Tue, 23 Jul 2019 12:08:23 +0000

I wrote this post for the CodeSandbox team, we're an online code editor that has a big focus on building a user-friendly application. This document serves as a guideline for everyone working on CodeSandbox, but I think it applies to almost any product. This document is never really finished, I'll try to keep it up to date with amendments/additions that may come! Let me know what you think should be added!

With CodeSandbox we value a fast response time and good product experience. I decided to compile a list of best practices on UI/UX and development (coding) to ensure that we, as a team, can keep these principles. This list is not complete: it only highlights the practices which I find most important. Also, keep in mind that these are guidelines, and might not apply to all scenarios. With this, our product (the app) keeps its feel of good UX/UI and we'll be able to maintain our speed and quality when building CodeSandbox.

UX/UI Best Practices

With CodeSandbox we want to be an easy to use application with the productivity of a power tool. This is quite a challenge, which is why it's good to write down our best practices on UX.

Some other applications that serve as a good example for us on this front are:

Superhuman
Framer X
Figma
Bear

Alongside these rules I highly recommend reading the fish shell design specification, it's an incredible resource that should be applied on top of these guidelines.

Easy for beginners, fast for pro users

Every feature should be designed for two groups of people with two flows; the "beginners" and the "power users". This means that beginners (people who haven't seen the feature before) should be able to find and use it with ease. Always ask yourself whether the feature is discoverable, not cluttered, and if the intent is clear.

Once the feature is clear and familiar for beginners, start looking into how power users can use it faster and try to educate them on this. An example of this is our dependency modal. Adding a dependency can be done with the mouse (easy for beginners), but we also hint that the user can press "enter" and the arrow keys to quickly select the dependency (power user).

Another example of this is shortcuts. It's important to clearly show users that they can use a shortcut to use the functionality that they've used often with the mouse. Superhuman does this well, they show a small popup at the button saying "You can do X by pressing Y" whenever you use your mouse to do X.

Feature discovery is tightly related to context. Showing that you can use a shortcut for an action doesn't make sense if the user hasn't used the action yet. Always ask yourself whether it makes sense to show the feature in this context. If we show all possible features and hints at the same time they will all lose meaning.

Try to make sure that your feature always works with & without the mouse. The mouse is often used when people are still unfamiliar, but after a while people will prefer to not leave the keyboard.

Avoid Asking Questions

Everything that users can use on CodeSandbox should have defaults. Giving someone a choice before they can use something should be an absolute last resort. Start with sensible defaults and allow the user to change them later.

Asking a question to the user adds to the mental overhead someone attaches to the product. Asking too many questions will leave an impression that CodeSandbox is an app that requires a lot of thinking, and is actually more work than it saves.

It's not only mental overhead that makes us want to avoid asking questions, it's also that we're most probably breaking the user out of their flow. If they're coding and want to add a dependency, we should not ask them to add it to "dependencies" or "devDependencies". If we know that 80% of the time they want it added to dependencies we should do that by default. Asking a question will break the train of thoughts, and thus break a flow. This is also why we should always think twice before adding a modal, modals often break the current flow.

This does not mean that we shouldn't make it possible to use advanced settings. When we start with sensible defaults (preferably based on their context, like sandbox type) we should still give the option to do advanced configuration. People that want an unconventional setting are already prepared to look deeper and tackle configuration.

One of the reasons that CodeSandbox exists is because we assume the build system for the user, so they won't have to think about it unless they explicitly want to. We need to pursue this ideal to all our UX decisions.

Clean UI

Always try to keep the number of buttons and choices as low as possible. Every button added is another new choice for someone to think about, and most users will bail out if they have too much choice. We don't want to become Eclipse. There is a balance here to be made, for every button added the other buttons will lose a bit of meaning.

This is related to feature discoverability, we should only make a feature discoverable if it actually applies to the current scenario (context). Showing all features at all times would only serve as clutter and overwhelm (and no feature will be discovered...).

Animations

Animations are great! When used well they can help with:

Awareness
- Where did this item come from?
- Did this button just change its state?
Overall Look & Feel
- I enjoy pressing this button because of its smooth animations
- This application feels very polished because of the last 10% polish in animations
- This talk by Joshua Comeau describes this really well
Making waiting more enjoyable
- When you need to wait for something, seeing an animation is far more fun than looking at a blank/static screen

And also important, they are fun to make! It's an artistic side to frontend development that many enjoy.

There is also the other side to this story. Animations are very pleasant in general, but if you overdo them the UI can feel more sluggish and slow. Think twice before adding an animation on "hot paths", which are actions that someone needs to do often and quickly. For example, making the hover in the file explorer a transition of background color will make the file explorer feel slow and sluggish instead of fast and snappy.

There is no rule of thumb that you can follow here, you need to feel for yourself if an animation will enrich the interaction or make it feel sluggish.

Development Best Practices

These best practices will make sure that it's easy for everyone to build and add functionality easily to the code base. The goal here is to have a fast turnaround time and quick experimentation, if you want to test something by adding a new feature that should be possible with minimal outside help.

Boy Scout Rule

The boy scouts have a rule: “Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.

The same is applicable to software development. Try to leave code in a better state than it was when you worked on it. There is no shame into fixing someone else's code, which brings me to the next point.

Code is shared by everyone

All the code that you write is shared by everyone, and this applies to everyone. There is no code ownership. Whenever you see a bug in code that you haven't written, or you want a new feature in an unfamiliar codebase, don't hesitate to work on that code and open a pull request!

If the change is very big, or you don't understand why the code is written the way it's written, also don't hesitate to ask the last author of the code before getting your hands dirty.

Move fast, always create an MVP first

Whenever you start working on a new feature, think about what the smallest thing is that you can build and deploy. Build that first and see how people use it. Don't overengineer and think of how people will possibly use it, try to build a basic version first and deploy it. Based on the usage you will know how people actually use it.

This doesn't mean that you shouldn't polish your MVP. Don't build something that's not polished. There is a difference between the size of a feature and how polished it is. People won't use an unpolished feature as much as a polished feature, the results from their usage will be skewed.

There are multiple examples where we applied this in CodeSandbox:

The browser bundler: the first version only supported JavaScript (no CSS) and didn't support more advanced features like import(). Based on the usage of the basic bundler we were able to prioritize and design a new bundler that supported more options.
The editor: the initial editor didn't have support for basic things like tabs, linting, autocomplete, type checking. Based on the response from the users we knew what to add first. We were able to prioritize based on feature requests.

Remember that you only have to design your feature for your current requirement set. There's no need to overengineer and predict how people could possibly use the feature. This is a waste of time and resources, and will often result in a development block.

Only refactor what you work on, keep the changes small

There is a huge cost to doing a refactor. It's a time sink, because all code that's rewritten needs to be reviewed and tested thoroughly for regressions. Even if it's tested thoroughly there's still a chance that bugs seep into the new refactor. Additionally, it's a source of merge conflicts for other people working on the same code. Automated testing and types help here, but you can't assume that these cover everything. Avoid full refactors, unless it's absolutely needed.

Because of the huge cost, it's often not wise to do a refactor. The only time we should do refactors is when the benefits outweigh the costs significantly. Think of benefits like:

Performance increase
Much, but really MUCH better code readability (code re-use & improved onboarding)
New enabled functionality/flexibility

If the benefits outweigh the costs significantly; try to keep the refactors as small as possible. Follow the MVP approach and never rewrite a huge part of the codebase all at once, this will allow us to keep the costs as low as possible.

Of course, refactors need to happen from time to time. Refactors make a lot of sense if you are already working on the code you're planning to refactor, we can refer to the Boy Scout Rule again with this. Because you are planning on testing the functionality anyway, the cost of doing a refactor is significantly lower if you're refactoring the code that you're already working on.

Conclusion

These are my most important best practices, I'm also curious about what you find important. What could be added to this list?