Hey all! I'm one of the co-founders of CodeSandbox and a big fan of Rust. Rust support is something that we've been working on for a while, but the recent addition of Docker support in CodeSandbox really enabled it. Happy to answer any questions!
I'd say that CodeSandbox has a strong focus on extending the existing workflow for developers. That's why we have a VSCode integration, a GitHub integration with a GitHub App that creates a running dev env for every branch/PR, and we make sure that generally all editor features you expect (autocomplete, go to definition, hover info, etc) are available for the languages that we support.
No, we've built our own web editor & iOS code editor. In our v1 editor we did run VSCode in the browser, but that was before code-server was released (in 2018). Even if we wanted to run code-server, that would be impossible as we allow for multiple users to open the same sandbox/branch, which wouldn't fit the model of VSCode server (which is single user per server).
I recently tried to work on CodeSandbox. Simple examples didn’t work or I couldn’t figure out how to make them work. Using repl.it now. I highly recommend to go through basic examples of frontend projects and evaluate them.
I'm using a web based IDE for my dev, but I'm biased in that sense. The main advantage for me is that I can easily switch branches, as every branch has its own VM. + I can easily share in-progress work. I do use the VSCode integration, because I'm very used to VSCode.
That said, I've also spoken with people who use a Web IDE next to their local environment. E.g. they use a Web IDE for reviewing PRs or making smaller changes, and they use their local editor for feature development.
If this is just for being able to easily switch branches, have you considered using git worktrees? Essentially you have have multiple branches checked out into different directories at the same time. The key point though is that all git refs are still maintained in a single place so you are not actually having full clones for each worktree that you have.
I personally use Emacs and magit which has great support for worktrees. I do not know if the VSCode git integration supports it.
Ah right, the main advantage I have here is that the dev server also stays running when I go to another branch (since it's a different VM). So I can work on one thing, share it with the team and in the meantime continue on another branch. They can see the devserver / running code, while I am working on something else.
It's especially useful for things like migrations or dependency management. In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
I didn't know about git worktrees though! I'm going to read up on this.
> In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
> In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
This is a good use case of git worktree.
> I didn't know about git worktrees though! I'm going to read up on this.
Indeed, you will like it.
The only limitation is that you cannot checkout the same branch in multiple worktree.
I use it with VS Code since the project I work on takes 5-10 minutes to build if a major header is modified. It shows up as a separate directory, but VS Code will still realize that the directory is a git worktree.
The only thing kind of clunky is that you have to keep track of which branch is open in which directory since you can't checkout the same branch in two different directories.
> The only thing kind of clunky is that you have to keep track of which branch is open in which directory since you can't checkout the same branch in two different directories.
I started using it while developing on a site running on nextjs. It works pretty fast and I can get things done faster. There are minor issues, of course, but in its current state it works just fine.
+1 - Personally not a fan of cloud IDEs - I am ok if the front-end for the tool itself is html based but run by/on a local http/websocket server. Having to maintain my entire stack on the cloud somewhere is something I still havent gotten comfortable (yes we use Github for source control somewhere and cloud for running you stuff somewhere). Then again I didnt get containers 15 years ago!
We use CodeSandbox for interviews (we have a base project that we fork for each interview). It's pretty good for watching someone code on a Zoom call (the actual pair-programming features like multiple cursors are a little buggy, but we don't need those).
I've also seen some open source projects that use CodeSandbox for their example projects. It's a nice experience for examples that require a server and client (that can't simply use storybook). I can understand the value in that, especially if you can automate it and link it to a Git repo with an examples/ folder.
I'm not really a fan of in-browser IDEs. To me, it seems like a good way to constrain tooling environments.
What I would love to see is an extension that runs all of my tests and debugger in a type 1 hypervisor that can simply send a set of instructions to setup the VM, a snapshot of the changeset, and allows a developer to run that exact environment on their machine. Combine that with LiveShare and you have something that closely mimicks the experience of handing a keyboard and mouse back and forth during pairing.
27 comments
[ 3.5 ms ] story [ 74.7 ms ] threadI know https://play.rust-lang.org/ is pretty limited as well.
I'd say that CodeSandbox has a strong focus on extending the existing workflow for developers. That's why we have a VSCode integration, a GitHub integration with a GitHub App that creates a running dev env for every branch/PR, and we make sure that generally all editor features you expect (autocomplete, go to definition, hover info, etc) are available for the languages that we support.
That said, it is something on our radar, being able to press a button for deploy from CodeSandbox would be valuable for many people!
I'd prefer having my own dev tools maintained locally by me but i'm curious if i'm becoming the minority
That said, I've also spoken with people who use a Web IDE next to their local environment. E.g. they use a Web IDE for reviewing PRs or making smaller changes, and they use their local editor for feature development.
I personally use Emacs and magit which has great support for worktrees. I do not know if the VSCode git integration supports it.
It's especially useful for things like migrations or dependency management. In one branch I could work on something that has some database migrations, and then I can still switch to other branches without having to roll back the migrations.
I didn't know about git worktrees though! I'm going to read up on this.
I would love to have this workflow locally.
You too should check worktree. (See my other comment)
This is a good use case of git worktree.
> I didn't know about git worktrees though! I'm going to read up on this.
Indeed, you will like it.
The only limitation is that you cannot checkout the same branch in multiple worktree.
The only thing kind of clunky is that you have to keep track of which branch is open in which directory since you can't checkout the same branch in two different directories.
"git worktree list" is your friend ;-)
I've also seen some open source projects that use CodeSandbox for their example projects. It's a nice experience for examples that require a server and client (that can't simply use storybook). I can understand the value in that, especially if you can automate it and link it to a Git repo with an examples/ folder.
What I would love to see is an extension that runs all of my tests and debugger in a type 1 hypervisor that can simply send a set of instructions to setup the VM, a snapshot of the changeset, and allows a developer to run that exact environment on their machine. Combine that with LiveShare and you have something that closely mimicks the experience of handing a keyboard and mouse back and forth during pairing.