It’s time for the second announcement of CodeSandbox! In September we made the announcement of CodeSandbox Containers, with containers we execute the code you write on a server instead of in the browser. This allows you to run almost anything you want on CodeSandbox, just like a local development environment.
When we announced this we gave the functionality the “beta” tag, we wanted to test it more before we would mark it as stable.
During this time, we flawlessly ran more than 23,000 container sandboxes, while considering users’ feedback, and iterating on the feature. It wasn’t all rainbow and unicorns…
We’re back with one of the biggest updates we’ve done so far! It’s very similar to the CodeSandbox 2.5 update one year ago. It includes VSCode extensions, many design tweaks, and a new devtool pane. CodeSandbox will feel far more polished from now on. Let’s get to it!
In October we released an experimental version of VSCode that you could turn on in your preferences. This replaced the core editor in CodeSandbox with VSCode, which gave us keybindings, user snippets, commands, editor grid view and much more from VSCode.
Since October we’ve been fixing a bunch of bugs and improved…
It’s time for a new update to CodeSandbox! This time we focused on the most important part of CodeSandbox: the community. Without a community, CodeSandbox would not be the platform it would be today, and it definitely deserves some more love.
We did three things to make it easier for everyone to find and share sandboxes. Let’s get to it!
I often get asked: “What’s the difference between CodeSandbox and <another online editor>?”. I don’t like getting these kinds of questions because:
For the same reason I get demotivated when I hear people say that CodeSandbox is like any other online IDE. Saying something like that makes me feel that whatever we build wouldn’t be noticed anyway.
CodeSandbox is often used to create new websites or to quickly edit existing websites. Until now this was only possible for projects that follow the default template layout, and if you wanted to change something like the webpack configuration you would have to continue locally. Well, not anymore!
Want to try a new GraphQL API server? That’s possible! Want to quickly add a new post to your Gatsby blog? …
Personalizing color schemes is one of the most important things to have in an application. It’s not only used as a way of styling to personal preference, it’s also very important for accessibility.
CodeSandbox didn’t have any way to personalize colors in the editor since release, but I’m happy to announce that we do now. The best part is that we were able to reuse a big chunk of logic from VSCode directly and thus we support any VSCode theme natively in CodeSandbox!
I will first highlight our pre-installed themes and fonts, then explain how to install your custom VSCode…
Starting new projects and sandboxes on CodeSandbox has always been very easy, but managing and collaborating on the created projects has been cumbersome.
We started to look into the management issues, and have come up with something that makes it much easier to organize and edit your sandboxes in bulk. This will be the building block for existing features and new features to come, including one we want to announce today as well.
Today we’re happy to announce Dashboard and Teams. Along with these two new features we now make CodeSandbox Live free for everyone! Let’s take a look!
I started CodeSandbox with the ambition to make sharing and collaboration of web applications easier and more accessible. Nowadays it’s being used for documentation, job interviews, prototyping, troubleshooting, bug reports, workshops, and probably much more.
Today we want to announce a feature that improves all existing use cases, but moreover will improve collaboration even more and allow for new ways to use CodeSandbox. It’s called CodeSandbox Live (original name!).
You can see an introduction video to CodeSandbox Live here:
From now on you can open up your sandbox for real time collaboration. By clicking on the ‘Go Live’ button…
From day one we’ve always tied templates to a CLI. The main reason for this is that we want to keep sandboxes simple, you shouldn’t need to do any configuration to get started. I didn’t want to create a ‘Vanilla’ template because there was no way to create ‘vanilla’ web projects without configuration, until recently.
Last year a tool called ‘Puppeteer’ was released by the Chrome Developers team. This tool is a headless Chrome, which means that with it you can interact with and visit websites programmatically. This is a powerful concept that has many uses.
CodeSandbox uses Puppeteer extensively nowadays. I want to explain in 2 posts how we use Puppeteer. In this post I will explain why and how we use Puppeteer for our test suite. In the next post I will cover how we use Puppeteer and serverless functions to generate previews and metadata for sandboxes (projects).