CompuIves

Also, while it uses the CodeSandbox bundler, you can self host it so it's not dependent on our servers!

First of all, super cool to hear that you've been such an early adopter of CodeSandbox! Not many can say that.

The fact that we made your projects public and kept charging is definitely a big mistake, and shouldn't have happened in the first place. When you cancel a subscription, we should keep your existing work private. Could you send me an email at ives@codesandbox.io so we can fix it?

Apologies for the fact this happened to you, that's a severe mistake and shouldn't have happened!

Yep, it downloads and compiles dependencies on the client side. However, it does this on a different domain for security reasons.

Replay has been amazing for me to debug hard to reproduce issues like live collaboration issues. You just record the bug, share it with others, place some console.logs (after the fact!) and scrub through the recording to see where things went wrong.

Also nice side-effect is that it's amazing to explore other code-bases, just being able to put a console.log somewhere to see how often it's run when using an application is a lot of fun.

The exact same has happened with CodeSandbox, Google Domains had blocked our csb.dev (internal domain) and csb.app (domain for projects) without any warnings. It took us two days (of downtime!) to get them to lift the block. But then after 3 weeks, they did the exact same thing! They blocked us again for reports without warning. Luckily we had a fallback domain so that there was not much service disruption, but it was extremely frustrating working with them on this.

After 3 sudden blocks from them, they now give us a warning before they're planning to block us, but it took many calls before we got to that stage.

We've been using Elixir for our API server from the start. It's a great language and scales really well. We needed to add a websocket API at some point, and now it's our channel with most throughput. Phoenix handles it fine, and we're still able to triple the throughput comfortably.

The one thing that we struggled with Elixir with is that it's quite hard to find people that know Elixir. For a long time I was the only one doing Elixir in the company, which introduced a bottleneck. That said, when you find someone who knows Elixir they tend to know Elixir (and a bit of infra) quite well.

That's a really good point! I deployed a new update with .pug support in vanilla, here's a sandbox to play with it: https://codesandbox.io/s/mjln1846k8.

I am so happy that we're on Hacker News!

If you have any questions about how things work in CodeSandbox don't hesitate to ask me! I'll watch this thread to answer any questions.

Hello! Creator of CodeSandbox here!

I don't want to give a comparison of StackBlitz and CodeSandbox, because my view as one of the creators would be skewed. I want to note though that CodeSandbox existed before StackBlitz released, I published CodeSandbox in April ([1] [2]) and StackBlitz released in August [3].

[1] https://hackernoon.com/codesandbox-an-online-react-editor-b8...

[2] https://news.ycombinator.com/item?id=14022860

[3] https://medium.com/@ericsimons/stackblitz-online-vs-code-ide...

I moved the sandbox to here: https://codesandbox.io/s/3rrq6yx9v1. I'm also curious, how did you find out about the sandbox.config.json? I feel like it's pretty undocumented by now, we could definitely improve on that.

1) Thank you!

2) Ah that's really stupid of me, `.stream` was our staging server. I should mention this somewhere, codesandbox.io should have the latest version with live.

3) Good one! I'll update it.

4) That's a super nice sandbox, I love tutorials that use gameplay, makes it much more fun to learn. I'd move it to the io domain, because our stream database is horribly outdated. I'll add a redirect from stream soon to avoid confusion.

Thank you! Yeah we moved to Kubernetes yesterday!

I learned most from the official Kubernetes tutorials (https://kubernetes.io/docs/tutorials/). I also used mix_docker (https://github.com/Recruitee/mix_docker) as a reference on how to build the image. The advantage of Kubernetes is that you can have the same way to deploy for all servers, so if you learn how Kubernetes deploys you automatically know how to deploy Phoenix applications.

Ah, I always forget to keep that page up to date. I'm sorry for that. Since CodeSandbox 2.5 we got some new things, like Parcel support, Typescript configuration support and some other things. I'll make sure to keep that page more up to date.

And if you really want to make sure, we're open source: https://github.com/CompuIves/codesandbox-client.

Thank you very much! It was definitely one of the most fun features to build.

I started working on this on March 15th, and the past few days was about testing everything, preparing the release and squashing bugs. The advantage of this type of functionality is that there are tons of high quality papers and articles already written on the subject, especially this one helped me a lot: http://www.codecommit.com/blog/java/understanding-and-applyi.... There were a lot of sleepless nights involved too.

I'm not sure about the VS Code and Atom teams, but I imagine that there are more constraints and there is more functionality to implement since they work with hundreds of potentially big files. I think those factors make it harder to implement this functionality than in the case of CodeSandbox.

Thank you very much! I appreciate it.

Thank you! Our backend server is an Elixir (Phoenix) server. It has a separate Elixir process for every current live room, we store all state in Redis. So in case we do a rolling deploy we won't drop any connections and continue where we stopped.

The server is mostly responsible for keeping all room state (the editors, the owner, operations per module) and transforming operations. When an operation comes in at the server, like an insertion, the server will check what revision that operation is at and transform it accordingly if the sent operation is based on outdated code. Then that operation will be broadcasted to the clients and again transformed on the clients to handle any inconsistency.

The library we use for doing the transformations is called ot_ex.

I hope this quick view is clearly written, let me know if there are any other questions!

Hey everyone! I'm the author of this post, I'll be here to answer any questions.

I did see that tweet. Maybe I was a bit unclear. I mean that the whole editor itself doesn't open when you don't have a connection (at least for me). My reproduction steps are:

1. Open https://stackblitz.com/fork/react

2. Disconnect from internet

3. Refresh the tab

At least for me this gives me a 404. I'm on Chrome. However, when I open the preview tab while offline it doesn't 404 on me.

CodeSandbox does almost everything in the browser however. The only thing it doesn't do in the browser is dependency bundling, which StackBlitz does in this case.

Essentially CodeSandbox can work offline if you already had the website open while you're online, then you can still continue offline. StackBlitz has the advantage that the tab where your application is can also be opened initially offline, which is handy for showing your application when you have no connection, but if I'm not wrong you cannot continue developing offline. I'd love to hear that I'm wrong, I'm really impressed with StackBlitz.

I'm the author of CodeSandbox btw :).

Thanks! I'm still thinking about open sourcing it. I'm also planning on writing a blog post on how things like NPM are implemented in this application.

For now a quick summary of what we use now:

1. Phoenix/Elixir for the API

2. Node for bundling NPM packages

3. Postgres for SQL

4. Redis for caching NPM package metadata

The editor itself is written in React (hah!) and uses styled-components, redux, redux-thunk and react-router@4.0.0 as most used libraries. I code split every optional preference a user may have (like autocomplete, vim or prettify) using webpack 2.

Everything is hosted on Vultr (20$ node).

I'd love to answer more if you have any questions.

Hey HN! This is a project I’ve been working on for the past few months. With CodeSandbox I want to focus on a feature of React that, in my opinion, could be exploited much more, which is reusability. With CodeSandbox you can easily build and share a React project with anyone by just sharing the url, others can then fork it to make changes or download it (which includes the default `create-react-app` template).

The next thing I’m building for CodeSandbox is the real reusable part: it should be possible to publish any project you have on CodeSandbox to NPM with a single click and let others reuse it as much as they like. An example is that someone makes a button on CodeSandbox and publishes it, others can then use this button inside CodeSandbox or in any project out of CodeSandbox. Publishing is already done, I’m now working on UI so publishing and searching sandboxes becomes easier.

I’d love to hear any feedback or suggestions or problems you might have! I want to make CodeSandbox as friendly as possible.