Web Workers

A very important improvement is that almost all transpilation happens in parallel using a web worker pool manager based on your amount of cores. This means that we use separate threads for transpilation, so transpilation happens in parallel by default. This removes load from the UI thread (reduces stutters) and also greatly improves transpilation time: for me the transpilation time (and thus loading time) was 2 to 4 times shorter! Transpilation is the only asynchronous stage of the three.

What happens if you move Babel into a web worker?

Code Splitting

Every loader is dynamically loaded based on their usage. If your sandbox only contains javascript files, we will only download the Babel loader. This saves a lot of time and bandwidth, since transpilers tend to be very big.

Offline Support

One of the requirements of the bundler is to work offline, that’s why all the unused loaders are still downloaded in the background by a service worker. There are no external dependencies while working on a sandbox, so after downloading the transpilers it can bundle offline whenever wherever.

Evaluation

Although I’ve called this bundler a ‘bundler’, there is actually no bundling happening! We already have access to all the code, so the only task left to do is evaluation of the correct file. The entry point gets evaluated using a simple eval , we provide a stubbed require that resolves the correct TranspiledModule and either evaluates it or returns the cache if it exists.

‘Hot Module Reloading’

The output of transpilation and evaluation are cached. When a file changes we throw away the transpilation of that specific file and compilation of that file and all parents (all files require ing that file). From that point we transpile and evaluate from the entry point again. I put HMR into quotes, because this is not the same implementation as the real HMR solution. We don’t have ​module.hot ​, because it would take a setup to make HMR work in a sandbox and I wanted it to work out of the box. (edit: we now do support module.hot since CodeSandbox 2.5!)

Conclusion

I’m proud of this bundler, as it allows us to do more and is also much faster than the previous version. With the new implementation we have the best of both worlds; we have a close API surface with Webpack and it’s optimized for CodeSandbox and the browser. It’s of course not as advanced as other solutions like Webpack, but it’s perfect for CodeSandbox. It now doesn’t take longer than an hour to add a new template and loaders are very easy to port from their Webpack counterparts. This makes us very flexible in the future.

Performance

The performance has also improved with the new bundler. Initial load time can be pretty high, because the transpilers need to be downloaded. All transpilers are cached using service workers or browser cache though, so on second try it should be much faster. Initial compilation takes between 1 and 2 seconds on my Macbook 13” 2015, all recompilation takes between 35 and 40 milliseconds(!). These tests were run on the TodoMVC implementation of Redux. It’s faster because transpilation now happens in parallel on separate threads and transpilation already starts while dependencies are being fetched.

Source

If you want to see the real goods; you can find the source here: https://github.com/CompuIves/codesandbox-client/blob/master/src/sandbox/eval/manager.js. This is the Manager class, it’s responsible for connecting the Sandbox , the Preset and all TranspiledModule s.

Future

The new bundler opens a lot of exciting possibilities. The two biggest are custom template support and full offline support.

Custom Template Support

We now have all these loaders like sass and typescript, it would be nice if we could also unlock these for the React sandboxes. There should be a button to eject a sandbox, which enables you to specify loaders and things like custom babel configuration. The main work for this has already been done, we only need the API to support it next.

Full Offline Support

Everything works offline already, but for full offline support we need to allow you to save sandboxes offline. This allows you to work offline on your projects forever, and upload to CodeSandbox whenever you’d like. The only feature that requires an internet connection are npm dependencies, but we already cache all npm results. We’ll give you the option to precache combinations for when you’re planning a trip or flight.