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, though, we had a few (expected) glitches along the way. So we worked hard on improving both the infrastructure and the implementation, and we’re quite confident to mark this feature as stable beginning today!

Some examples of Container Sandboxes

We saw many new kinds of projects on CodeSandbox as soon as we released containers, we want to highlight some of the craziest and best ideas built on CodeSandbox.

React Native Expo

Phil Plückthun created a sandbox that runs Expo! This way you can build React Native apps directly on CodeSandbox.

Nuxt.js Examples

One of the best examples we can give you for the stability of containers is the homepage for https://nuxtjs.org/ as they have been running them from almost the start and have been integral in testing the resilience of our containers. This is their starter example.

Next.js, Gatsby, Apollo Documentation

Containers have also been used a lot by Next.js, Gatsby and Apollo for their documentation and examples. They have set up GitHub repositories that link to sandboxes to showcase how their frameworks work. If you’re interested in setting this up for your framework, don’t hesitate to shoot us an email to hello@codesandbox.io!

Here is a Gatsby, Next.js and Apollo example.

Node Streaming Example

Another cool example is the node video streaming demo, showcased here. It shows how you can stream videos using Express.

The possibilities are endless!

Updates

We’ve been doing many improvements since the initial release. Here are the highlights of what we built and improved.

Infrastructure Changes

Last week we moved our sandbox containers over to a new infrastructure, which resulted in a big speed improvement for our containers. We upgraded the storage nodes to NVMe drives, we are using a new Kubernetes version (1.13.4) and added more servers to run the sandboxes in. As a result, we also increased the time of inactivity to hibernation to 60 minutes instead of 10 minutes.

A detailed post about infrastructure, architecture and software stack is coming soon!

Raised limits

Up until now we you were able to create up to a maximum of 5 container sandboxes as regular user, and you had a limit of 20 sandboxes as a patron. Today, as we mark the service as stable, we are increasing the maximum number of container sandboxes to 15 for anyone and 30 for patrons. We may raise the limits based on usage in the future.

Another change we made is that from this moment on any sandbox that is in the “Trash” folder does not count towards this sandbox limit. This also applies for the 50 sandbox limit on client sandboxes.

Secrets Support

You can now add environment variables to a container. The variables will be hidden for others and will not persist between forks. This is perfect for showing demos/examples of APIs without exposing any secrets.

Future plans

We have big plans for how our containers will work in the future, we want to give anyone access to a docker instance with the click of a button. We want to make some additional features and changes to make this easier.

Some of our ideas are:

Importer Improvements

Right now we only detect official templates when you import a sandbox from GitHub. If you want to import a node container you need to have a sandbox.config.json mentioning that the template is node. We want to make this more streamlined by doing some smart detecting. If, for example, we see you are using webpack or express we will automatically convert that into a container sandbox

Restart Container

Sometimes containers get stuck and that’s not nice at all. One way we want to mitigate this is by adding a “Restart Container” button that will restart your docker container.

Convert Sandbox to Container Sandbox

We often saw that people started working on a browser sandbox, but then outgrew its size after a while. Maybe because you want to access the terminal or because you want a helpful command line to help you generate the files.

This is a big pain-point for a lot of our users, particularly in angular, so we will make it possible to convert any sandbox to a container sandbox in a click of a button. When you click the button we will create a fork of the sandbox backed by a container, so you can install and run whatever you run on your local machine.

Wake Up Containers with API Call

What if you could use your sandbox as a really simple API? That’s our idea too!

One thing we plan to implement now that the containers are stable is a way for the sandbox to wake up as a request is done so that you can get a proper API response from a container sandbox at any time. This will make it much easier to actually build APIs and bots using CodeSandbox!

Always-Running Sandboxes

Sometimes you create a server sandbox that you want to run forever, right now this is not possible since we will “hibernate” this sandbox after a while. This is also something we plan to add as a feature so that if you have a container sandbox embedded in the documentation, this sandbox will never be stopped.

Conclusion

This has been in the works for a while and it was a real strive for us to complete and honestly could not be done without the amazing work that Bogdan puts into making CodeSandbox better and faster every day.

We hope you love this update as much as we do, and to anyone who has been with us since the beginning of containers, thank you for making it better with your feedback and suggestions!

We can’t wait to see what you will build!

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!

VSCode Integration

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 the general integration. From now on we’ll run VSCode as the only editor in CodeSandbox, and with that, we decided to give the editor a new look! Here’s what was added with the new integration:

Extensions Support

We now support VSCode Extensions! The cool thing about this integration is that everything runs in the browser. Instead of spawning node processes, we spawn web workers with stubbed node modules like fs, net and module. This means that there’s less latency and there’s no need for us to run servers for VSCode. I’ll do a better write-up on how this works after all the remaining releases.

Initially we’ll support a predefined list of extensions, we’ll gradually open up the possibility for everyone to add and install their own extensions.

VSCode Extensions comes with a lot of new functionality, I want to highlight some of the things that I found nice:

Native TypeScript Type Checking
The TypeScript extension runs exactly the same as the local VSCode installation, it now reads tsconfig.json , will give the same autocompletions and it runs the latest TypeScript version.

Auto Import
Automatically importing variables from your own files or dependencies now work!

Refactoring Support
You can also use the same refactoring options as in VSCode, like refactoring a function from promises to async, or moving a function to a new file. It works exactly the same!

VIM Extension
We also include the VSCodeVim extension by default, you can enable it by opening preferences and going to Editor.

Vue & Vetur
We also run the Vetur extension from source, which gives the same autocompletions, linting, and prettifying as VSCode. It is really powerful, this also includes the recent addition of autocompletions in templates.

Minor Improvements

We also added graphql, styled-components and yarn.lock syntax highlighting/autocompletions using the new extensions. Small quality of life improvements!

Existing Functionality in VSCode

Functionality that didn’t work before, like the configuration UI and the image viewer now work in VSCode as well. We added some custom editor types that are actually rendered in React, which is quite interesting. We now mount VSCode in a React application, and we mount React in the VSCode view.

A New Design

Since we’re now full-on on VSCode it was high time to adjust the design to fit better with this code editor. We tweaked the design in many ways to give a more coherent and less cluttered feel. I’ll go by the changes one by one.

Devtool View

The browser preview has become multi-functional! We added tabs to the preview (devtool) view that you can use to switch between different devtools. Browser is the default devtool, but if you think that the console is more suitable for your example you can just drag the tab to the first place to make it the default!

We think that this new devtool pane will make it easier for people to demo things like tests or console output. This also affects the embed. Here’s an embed with the console pane as the first tab. Expect to see more devtools added in the future!

Menu bar & Status bar

One big contributor to a cluttered look of the editor was the header. There were so many buttons that it became hard to actually find the button you were looking for. We decided to change this by removing a bunch of buttons and by putting them under a menu that’s familiar to many of you: the menu bar! We removed all buttons that are not relevant to the editing experience (who goes to “Explore” from the editor?) and put them in the menu bar.

We also added a status bar, the functionality of the status bar became more useful as we added extensions and support for the image view, for example. We’re planning to use this status bar quite a bit with CodeSandbox integrations in the future.

Both the status bar and the menu bar are taken directly from VSCode! This is one of the advantages of having VSCode as our single editor.

Color & Themes

Together with the new UI parts we also have a new color theme and new icons. You can expect to see the CodeSandbox color theme in the VSCode marketplace in the future!

Confusing Parts

Previously we would hide the activity bar (left most bar) when you were viewing a sandbox that you don’t own. We’ve reverted this, it turned out to be quite confusing for people when they saw CodeSandbox for the first time.

Conclusion

I hope you’re as excited about this update as I am! We’ve been working a long time on this, and it’s great that we can now show it to everyone. Let us know what you think! Did you find something that didn’t work? Please let us know on our repo: https://github.com/CompuIves/codesandbox-client.

Also a huge thanks to all contributors who have contributed to CodeSandbox, we already have 114! The list almost getting too big to show in one image!

This update is the first of 4 updates that we’re releasing this week. Stay tuned!

Announcing CodeSandbox v3 was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

Explore Page

CodeSandbox always strove to make itself the best way to create experiments and to prototype apps, but until now there was no way to see the experiments unless you found the perfect Twitter thread. While working on CodeSandbox we found so many hidden gems, and we feel like we should bring them more to light.

That’s why we’re happy to announce the explore page! A page with hand-picked sandboxes which we deem either interesting, beautiful or both! We have invited a group of curators who can pick sandboxes that go on the explore page. We constantly pick new sandboxes for the explore page.

Please send us all your cool sandboxes by tweeting with a mention to @codesandbox, so we can feature you on the explore page!

We created a documentation entry with answers to some questions about the explore page here.

Move to Spectrum

We’ve always been using Discord for communication with the community. As the popularity of CodeSandbox grew we started to notice that it was hard for everyone to keep up with all the chatter. Furthermore, we received many duplicate questions that were answered before.

We’ve seen so many amazing things happen at Spectrum that we made the decision to move our community there. Spectrum solves all the issues that we had by giving a thread based conversation model, another big plus is that everything is searchable from search engines!

This will make it easier to ask questions and to share your ideas and work! If you want to be a part of it you can join it here.

Submit Feedback

The “Submit Feedback” button is back! If you have any ideas for a new feature, or you just want to let us know your thoughts, you can do that now from the user menu. We’ll stay on top of all the feedback.

The future of the community in CodeSandbox

That’s where all of you enter and get to join this discussion to help us better shape the community we are trying to create. Join our Spectrum and tell us your ideas. We all have valuable ideas that can make CodeSandbox better and better every day.

Let us know for what you use it and what is missing and we can all build this community together and make it better!

Thank you

Thanks to everyone working on this update. A special thanks to Sara Vieira for putting an incredible amount of effort in this update, she did an incredible job in making this happen.

Also thanks to you! Without your sandboxes we wouldn’t have anything to put on the explore page to begin with!

I often get asked: “What’s the difference between CodeSandbox and <another online editor>?”. I don’t like getting these kinds of questions because:

1. I am extremely biased, any answer or comparison I could give would be unfair to some extent.
2. I like to work on unique things, comparing alternatives to what I build infers that what we’re doing has already been done before. That demotivates me.

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.

That’s why I decided to write down everything that I think are the defining big features of CodeSandbox, features that you cannot find in many other IDEs. This way I can always link to this post when someone asks me the question, without making a direct comparison.

Live Collaboration

When working on a sandbox you can open up a Live Session. This generates a unique URL which you can give to others to join your sandbox and collaborate live (google docs style) together with you. As the owner of the sandbox you can also enable ‘Classroom Mode’, this mode allows you to specify who can edit the sandbox and who can only view. This is especially useful for workshops or situations where more than 30 people connect at the same time.

GitHub Committing/Forking/PRing

Besides importing from and exporting to GitHub we also allow you to work on a GitHub repo directly. When forking a sandbox that’s imported from GitHub you can make changes and either create a PR or a commit with the changes when you’re done. If you don’t own the repository that’s no problem, we automatically fork it for you and create a PR.

VSCode Integration

Since recently we have an experimental feature (you can enable it in settings) called ‘VSCode in the browser’. The name really says what it is, we have created a fork of VSCode that works in the browser. Because of this we get Grid View, Keybindings, User Snippets, Breadcrumbs, VSCode Settings and more. You can copy your settings files directly from VSCode to CodeSandbox and we should have the exact same keybindings, snippets and preferences.

I want to clear up that this isn’t only Monaco, but also parts of VSCode (like the previously mentioned features) that weren’t ported to the browser yet.

Container Sandboxes

Another recent addition is Container Sandboxes. Previously we would run a sandbox in the browser. This works great for many sandboxes, but imposes a limitation on what you can run. With Container Sandboxes we actually run the code on a server, this makes it possible to eg. create a Node/GraphQL server on CodeSandbox. It also opens up the possibility to create Next/Gatsby/Nuxt projects inside CodeSandbox. It runs anything that works locally.

Dashboard & Teams

Everyone has a dashboard that they can organize their sandboxes in. In this dashboard you can create directories (like Google Docs) to categorize your sandboxes. You can also search, filter and sort the sandboxes whenever you need to find a specific sandbox. We show a screenshot of every sandbox so you can visually filter them.

Another feature of the dashboard is the option to create teams. As a team you can share ownership of sandboxes and work on them together. There is no limit to team sizes and whenever multiple people from a team open the same sandbox we automatically create a live session.

Beginner Friendly Tricks

We try to make CodeSandbox useful for people wanting to learn web development. That’s why we show error suggestions for some errors (like ‘Add Missing NPM Dependency’ or ‘Rename “App” to “App.js”’). For known configuration files we show a UI and description.

We also have a search page, on this page you can search for sandboxes (850.000 at the time of writing) when you need to find any examples. You can filter on dependency, on template and on tags to make it easier. If you, for example, ever want to know how redux is used you can filter on that dependency and shift through the examples sandboxes.

Deploy Sandboxes

We have a deployment integration with Now. When you want to create a production version of your sandbox you can click ‘Deploy Now’. This will deploy the sandbox, install the node_modules and start it under a new URL. We then give this URL back which you can alias to any domain that you like.

We are also adding support for other deployment providers in the near future!

Smaller Factors

These are the features that I think are worth mentioning, but don’t deserve a header of their own.

Private/Unlisted Sandboxes
As a Patron you can create sandboxes that are either private (not viewable apart from you/your team) or unlisted (not viewable from search) sandboxes.

Jest Support
We have support for running Jest tests and have a small dashboard for it where you can manage the tests and control them.

We’re Open Source!
The frontend and the microservices of CodeSandbox are open source! This is the place where you can find out how CodeSandbox works. We currently have 97 contributors and are always welcoming more!

Conclusion

This is a list of things that you can do with CodeSandbox, but I don’t think this truly defines us. I think our values, our drive and our ‘out of the box’-thinking is what produced all these features, and will certainly define what we’ll be able to make in the coming years. I really can’t wait to see what the future holds and I’m looking forward to work on this online editor as long as I can.

These features are not only built by myself, we now have a big group of people working on CodeSandbox. I want to thank Bas Buursma, Bogdan Luca, Sara Vieira, Christian Alfoni for their work, and also a big thanks to the other 93+ contributors who have added features, documentation and support! If you’re interested in helping us out, this is our repository with the most activity!

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!

Today we’re happy to announce CodeSandbox Containers. We execute your code on a server, which allows you to work on any JavaScript project that works locally.

Want to try a new GraphQL API server? That’s possible! Want to quickly add a new post to your Gatsby blog? You can do it from CodeSandbox with its GitHub integration.

Along with this update we’d like to announce new templates running on this system. Everyone can now work with Next.js, Gatsby, Nuxt.js, Apollo Server, Node and ReasonML right from within CodeSandbox! We give first-class support for these templates, but you will still be able to run anything you want on CodeSandbox. You can create a new project here.

Run Any Project

Until now we’ve executed all code in the browser. This has many advantages: it’s snappy, it works offline and there is almost no load for our servers. There is also a counterpoint to this: you won’t be able to run node directly.

With CodeSandbox Containers we execute your code on a server, which allows you to literally run any project without checking if we support it. I will go through all the main features added specific to CodeSandbox Containers.

See what happens on the dev server

We introduce a new view for the toolbar called “Terminal”. This view will show the output of yarn start when the sandbox starts.

Run any NPM Script

We also introduce a new panel in the side bar called ‘Server Control Panel’. This panel gives you the opportunity to run any script specified in package.json in the terminal. With this you can quickly lint or run tests or any other script.

This doesn’t only work for npm scripts. You can also open a bash shell to explore the sandbox! Note that we do monitor the sandboxes, if we notice any harmful behaviour we can block your account.

Templates Galore!

We hope you are as excited as we are about this update. The best thing is that you can use all our existing features with these new templates! For example, you can live collaborate with others on a Gatsby template or quickly create a new post for your Next.js website using our GitHub integration.

Go check out what templates we fully support here: https://codesandbox.io/s.

ReasonML

One template we added is ReasonML! We don’t execute ReasonML on the server, but in the browser. We are still testing Reason and could use all your help, so if you find anything out of order don’t hesitate to send us an issue!

Beta and Thanks

We can only test CodeSandbox Containers fully when we have other people using it. So we currently give the warning that CodeSandbox Containers is in beta. Please don’t use it for any project with files you don’t want publicly exposed. There’s also the chance that the service might be down because of things that we haven’t foreseen yet, in which case you’ll see a nice warning message. If you notice this happening and want to know what’s going on, you can find us here.

We will dedicate the coming months to squash every bug we can find, when we think that CodeSandbox Containers is stable enough to remove the beta warning we will announce this. In the near future we will also work on more documentation about containers so that there can’t be any confusion in the differences between client and server sandboxes.

There is no way to sync the changes from the terminal back into the sandbox itself yet. This is top on our priority list and we will get this in as soon as possible!

We have a limit of 5 server sandboxes for free accounts currently, we have a limit of 15 server sandboxes for Patron accounts. These limits will probably change.

Thanks

We’ve been working on this functionality since February now and are extremely happy that we can share this with everyone now.

There are some people that deserve a huge thanks for this endeavor.

We want to thank Bogdan Luca for building the whole infrastructure for CodeSandbox Containers, this is an incredible undertaking and he pulled it off.

We also want to thank Gatsby for inspiring us to start this and for being both our counselor and funder of this project. Kyle Matthews and Sam Bhagwat were extremely supportive and helped us think everything through while also relieving us of other worries.

I’d like to close with our new loading screen for containers. 😃

Announcing CodeSandbox Containers was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Start using any VSCode theme directly in CodeSandbox

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 theme and I will end with an explanation on how it works (spoiler alert: WebAssembly).

Pre-installed Themes & Fonts

We have made a selection of VSCode themes that we think are important to have ‘pre-installed’. In reality we still download them on-demand, but you can easily make a selection between these themes without opening VSCode. If you have a suggestion for a pre-installed theme don’t hesitate to open an issue!

CodeSandbox (new syntax highlighting)

Night Owl by Sarah Drasner

Atom One Dark by Mahmoud Ali

Atom One Light by Mahmoud Ali

VSCode Light by Microsoft

Dank Mono (font) by Phil Plückthun

We now also enable Dank Mono as pre-installed font by default. This is an incredible font created by Phil Plückthun. It supports italics and font ligatures (you can enable those in preferences). He explains here what the design choices behind Dank Mono are.

You can choose between the fonts ‘Dank Mono’, ‘Menlo’ and ‘Source Code Pro’. You also have the option to install any font that you have locally installed.

Installing a Custom Theme

There are a few simple steps to move your own VSCode theme to CodeSandbox explained here:

1. Open VSCode
2. Press (CMD/CTRL) + Shift + P
3. Enter ‘Developer: Generate Color Theme From Current Settings’
4. Copy the contents
5. Paste them in CodeSandbox Preferences

Here’s a GIF of copying over a theme:

How It Works

CodeSandbox has been using Monaco as its main code editor for almost a year now. Monaco is the core editor part (the part where you write code in) of VSCode, and the team behind VSCode was so awesome to make this part work in the browser directly as well.

However, the syntax highlighting of VSCode uses .tmLanguage (from TextMate) to tokenize all the code. And parsing .tmLanguage requires a C library called Oniguruma to parse and execute the regular expressions, which has a specific syntax. That’s why the VSCode team put in a different tokenizer into the browser version called Monarch. This tokenizer is not fully compatible with VSCode themes, which made it hard to directly port them over.

However, a year passed by and WebAssembly is gaining a lot of traction. We found out that a library called Onigasm (get it, OnigurumaASM?!) was released, this is a compiled WebAssembly version of Oniguruma with 1:1 support. Quickly after that I found out that the same author(!), NeekSandhu, also published monaco-editor-textmate, which allows you to tokenize .tmLanguage files for Monaco!

This was enough information to make VSCode themes be supported directly in the CodeSandbox editor through the tmLanguage tokenizer. The only thing we had to add was a mapping of the rest of the UI to the VSCode colors. We are using styled-components for styling, so that was a matter of putting the VSCode styles in the ThemeProvider and changing the style of all elements one by one.

Other Features

We also updated our Monaco editor to the latest version (we were on v8, which is a year old). Because of that we now get proper keyboard support for iPads in the editor. I also rewrote the logic in the editor itself, which now gives:

• More robust CodeSandbox Live, there should be less bugs
• More performance in the editor itself and when switching files (I used the trick described here)
• Autocompletion for import statements (I learned about that here)
• Less bugs when switching files

Thanks

I want to give a huge thanks to Sara Vieira, she came with the idea to do this when we were on our way to Brighton and she helped tremendously in building and debugging this functionality. 10 👍 for her!

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!

Dashboard

You now have a personal dashboard for organizing and finding your sandboxes. This dashboard has specifically been designed with the idea of a file system in mind.

Organize your sandboxes in directories

You can now organize your sandboxes by creating directories and putting them into the directories. Now you can finally properly tag your sandboxes by how and why you created them!

Modify multiple sandboxes directly

You probably have many quick test sandboxes that now only serve as clutter. With the dashboard you can select multiple sandboxes and edit them at the same time, including moving them to the trash.

Search, sort and filter through your sandboxes.

The last new feature to help you organize is the search bar! You can now search, order your results and filter through your sandboxes, including your private sandboxes and the sandboxes of your teams.

Teams

CodeSandbox is used more and more to collaborate with others, this is great! We want to make it even easier for people to get together and work together on a sandbox, so we’re happy to introduce ‘Teams’!

You can create as many teams as you like with unlimited people. As a team you have shared directories for your sandboxes, all the sandboxes in the team directories are automatically shared between team members.

Live Collaboration

This is the best part: we automatically create a live session between team members whenever they open a team sandbox simultaneously. This means that team members can immediately live collaborate on shared sandboxes. They can also share their live session with people outside of the team by sharing the Live URL.

Team Pro

We’re planning to release something called Team Pro in the future. Team Pro is a seat-based subscription that allows your team to create private sandboxes within your team. We haven’t released this yet, so you will now be able to do this as a patron. If you’re interested in this functionality you can subscribe by joining this mailing list.

That’s not everything

There are many more hidden features in this update. Here’s a sneak peak of what’s included:

Free CodeSandbox Live

One nice addition to teams is that we now make CodeSandbox Live free for everyone to use! We’re hoping that everyone collaborates even more on CodeSandbox with this change!

File Recovery

With this update you won’t have to worry about crashing browsers or flaky connections anymore. We now save your files in localStorage, so whenever you leave CodeSandbox without saving we’ll restore the session for you when you come back!

Design Tweaks

We tweaked some of our theme colors and restyled the buttons. The design of the editor should look a bit better now!

Disabled Back Gesture

Most OSX users noticed that when you slide back in the editor you will navigate away from the editor. This is very frustrating. We catch and disable this behaviour now.

Thanks

With this update we refactored the code quite a bit and we introduced some new libraries. I want to mention the introduced libraries and how they helped.

GraphQL and Apollo-Client

We built the dashboard functionality fully with GraphQL. We have lots of nested data on the dashboard with many different variations of structures (thanks to our ordering and filtering) and GraphQL handles that wonderfully. Apollo-Client made it easier to manage all the different forms of this data and allowed us to do the optimistic updates and caching more easily.

We also have mutations that often include multiple sandboxes and GraphQL was able to handle that very well.

react-spring by Paul Henschel

react-spring has made it so much more easy for me to do animations. With react-spring you can create animations based on state, but in a performant way thanks to their native mode. I converted all our animation logic to react-spring and it has been a blast so far.

Our dashboard is animated with react-spring, from the context menu slide-down to the sandbox dragging.

react-virtualized by Brian Vaughn

The dashboard works with many sandboxes, for my dashboard I had to show 400 sandboxes at the same time. React Virtualized makes sure that you only render the items that are in view, making the dashboard much more performant. React Virtualized also made it easier for me to organize the sandboxes in a grid.

Contributors

We want to thank all our 75(!) contributors to CodeSandbox. We’re open source, so don’t hesitate to check out our repo and give a star!

The Future

The dashboard is a perfect building block for the new features we’re working on. We have a lot more exciting announcements planned out for the coming month, so stay tuned by following either @codesandboxapp or @CompuIves!

Here’s already a sneak peak on what’s to come:

Gatsby on Twitter

Coming soon.....an online @codesandboxapp IDE for Gatsby! Stay tuned ;)

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:

Collaborate in real time

From now on you can open up your sandbox for real time collaboration. By clicking on the ‘Go Live’ button you will get a URL that you can share with others. They can then join your session and seamlessly collaborate live on the same sandbox with you. They will be able to create files, delete files, move files, write code, the whole shebang. You will see their cursors, selections and which file they’re looking at, while still keeping your own editor features like Intellisense.

Everyone can simultaneously change code in the same document, or choose to edit other files. We dynamically update selections, cursors and code based on the input of others, using Operational Transforms to resolve any potential conflicts.

Choose who can edit

CodeSandbox Live has two modes: ‘Open Mode’ and ‘Classroom Mode’. The default mode is Open Mode, which allows everyone to edit. Classroom Mode lets you select who can edit. This is especially useful for lectures and workshops where 30 students can look at the same sandbox. You will only see the cursors and selections of the people who can edit, the ‘editors’.

Fork at any time

If someone wants to continue with their own version of the sandbox they can simply do that by pressing ‘Fork’ at any time. They can later join the session again if they want to.

It’s in beta

It turns out that these kind of features are pretty hard to test by yourself or with some friends 😅. I tested this for a pretty long time without finding bugs, but we probably missed something. That’s why we want to mark this as a beta for the time being. If you find any issues you can open up an issue on our GitHub repository. To test the load we’ve marked this feature as Patron-only: a live room can only be created if you are a Patron, everyone can still join created rooms.

Test Sessions

There is no limit on how many users can connect to one live session, but we haven’t tested bigger crowds yet. In the coming weeks I will share live test sessions and streams on my Twitter, everyone is encouraged to join them!

How it works

I’m really happy with the implementation of this system. In the frontend we’re using parts of ot.js. On the backend we have our Elixir (Phoenix) server that runs a custom OT implementation together with ot_ex. Every live room is a separate Elixir process, and all state is stored in Redis to allow for temporary server disconnection or rolling updates. I will definitely write a more detailed post about this. There were some really interesting challenges, and many race conditions. It was one of the most fun features to build by far.

This feature has been a blast to build and test. I hope you’ll have as much fun using CodeSandbox Live as I had testing it! Let us know what you think on the CodeSandbox Twitter or my Twitter.

We’re open source

If you’re interested in the source of the frontend, you can find it here:

CompuIves/codesandbox-client

We’ve also recently opened an Open Collective for companies that want to support our open source work.

Introducing CodeSandbox Live: real time code collaboration in the browser was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Parcel

A new bundler called ‘Parcel’ was released in December by devongovett. Parcel is a web application bundler that values zero configuration. They reuse classic web concepts, like using index.html as the entry point of the application, which makes it really easy and intuitive to get started with a new project. You only have to create an index.html and run parcel index.html to get a working application. They automatically detect what kind of web application you’re running, and adapt the configuration to that if it’s not specifically set.

This is aligns perfectly with the values of CodeSandbox. There is almost no friction to get started, and all the needed configuration is automatically detected & installed. That’s why I decided to finally build a Vanilla template and use Parcel as our configuration behind it.

Vanilla Template

We have a new sandbox called vanilla, unlike other sandboxes, this sandbox has index.html as its entry. From this index.html you can add script and link tags to other files and they will be added to the bundle. We support all loaders that Parcel supports, so we support:

• Babel
• TypeScript
• SCSS/SASS
• LESS
• Stylus
• CSS Modules

We also recognize the difference between:

import styles from './styles.css';

and

import './styles.css';

In the first code block we will generate css modules from the css file, and in the second block we won’t.

You can try it out here:

Configuration

Like Parcel, we automatically do configuration for you. We automatically detect if you’re using react or preact and will adjust our Babel configuration for it. We do support Babel/TypeScript configuration, so you can also choose to do your own configuration by creating a tsconfig.json or a .babelrc.

GitHub, Zip Extraction & Deployment Integration

Like the other templates, you can create repos, make commits and PRs, download and deploy sandboxes using this template. Without leaving the browser.

Beta Warning

This is our first template that uses html as an entry point, so there can be bugs or unintended behaviour that still needs to be solved. Please let us know in the repo if you find any issues!

CompuIves/codesandbox-client

Thanks

I want to thank devongovett for building this beautiful bundler, I was able to effortlessly build an application in it. Great work!

If you like what we’re doing, consider becoming a contributor or a patron! You can stay up to date with CodeSandbox news either on @CompuIves or @codesandboxapp.

Introducing the Vanilla Template to CodeSandbox was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

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).

But Why?

In CodeSandbox we do all bundling of the sandbox code in the browser, I’ve built a custom bundler to do this. We still make changes and add features to this bundler, so it’s crucial that we extensively test if the changes affect existing sandboxes built by users.

Before

I’ve always kept a list of ‘test’ sandboxes and would load every sandbox manually to see if they still worked. As you can probably expect, this proved to be very time consuming as the list kept growing beyond 20 sandboxes and we started getting more contributions. Puppeteer to the rescue!

Solution

Puppeteer has a really nifty function called screenshot (you can try it here). The function does exactly what it describes: it takes a screenshot of the current webpage and returns the Buffer of the screenshot. For CodeSandbox we can use this as a snapshot tool: after every commit we take a screenshot of all test sandboxes and compare them with the previously stored screenshots. If there’s a difference of more than 1% we fail the test suite.

Implementation

I decided to use Jest for running all tests. We start by setting up an array of sandboxes to test:

This is a list of sandbox ids, of which some have extra options like a more tolerant threshold. We iterate this list to create test cases:

The biggest question was how to take a screenshot of a single sandbox. This turned out to be quite simple, we already support opening a sandbox as a separate page by going to https://:id.codesandbox.io (example: https://vue.codesandbox.io). So the only thing left for me was adding this functionality to the development server, so we can create screenshots with the new code. I ended up changing our webpack config to have a ‘test’ mode, this mode will only build the sandbox bundler and host it at http://localhost:3001#:id (example: http://localhost:3001#vue). Note that we set the id as a hash, this way we don’t interfere with the routing of the sandbox.

After having this set up it was fairly straightforward to build the rest. There’s already a library for comparing screenshots called jest-image-snapshot. This library exposes toMatchImageSnapshot on expect, which works almost exactly the same as toMatchSnapshot.

The final implementation looks like this:

You can see in the code that we expose a function called window.__puppeteer__. The bundler calls window.__puppeteer__ when it’s finished, this function is exposed by puppeteer so we can exactly know when we can take the screenshot. The generated screenshots are then saved in the GitHub repo. You can find them here.

We run these tests using CircleCI, but we need to generate the initial screenshots locally. To ensure that we generate similar screenshots as CircleCI we generate screenshots using a docker container. We have a simple script which we just run to generate new screenshots:

I have set up a simple workflow for CircleCI to start the test server and simultaneously run the tests. These tests are run in a docker container that has Puppeteer preinstalled.

We save all diffs as artifacts, so we can easily compare the screenshots. You can see a list of artifacts of a recent test run here: https://circleci.com/gh/CompuIves/codesandbox-client/4291#artifacts/containers/0.

Conclusion

The implementation turned out to be quite simple, but it has saved me a lot of time already. We now test a little over 20 sandboxes for every commit and PR. I also noticed that I’m more inclined to add sandboxes to the test suite too, which made the bundler more stable in general.

In the next post I will cover how we use Puppeteer with serverless functions to generate metadata and oEmbed tags for sandboxes. You can follow my Twitter @CompuIves or @codesandboxapp to stay up to date!

If you’re interested in the code; all code that was described here (and of CodeSandbox) is open source on GitHub. You can find the main repository here:

CompuIves/codesandbox-client

I hope you found the post interesting, don’t hesitate to respond with more ideas and uses for Puppeteer!

How CodeSandbox uses Puppeteer & Jest to test sandbox functionality was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.