StackBlitz WebContainers/Svelte[Kit] REPL integration

README.md

It's very unlikely we'd be able to upgrade the Svelte REPL into something that could run SvelteKit apps (and therefore be suitable for a SvelteKit tutorial a la https://svelte.dev/tutorial). I had a conversation today with Eric Simons from StackBlitz about what a WebContainer-powered REPL might look like, and whether it's something the Svelte team would want to pursue.

We talked through all the bullet points below, and Eric addressed various concerns:

• Expecting browser support issues to be more or less resolved by end of Q1 2022, which is probably around the timeframe we'd be looking at
• Most of the startup time is downloading stuff from npm (and in a SvelteKit app, most of that is Vite; it's possible there's some stuff we could do to slim down that package). The WebContainer itself is around 2MB IIRC. In a non-Kit REPL we could potentially take a simpler approach that bypassed npm altogether; it should be possible to have things start up in around a second in a typical setup
• The interface would be fairly low-level — basically we get access to a filesystem, a terminal, and a way to detect servers listening. We have full control over the UI (in other words we could implement the existing tutorial experience with near 100% fidelity, including using a local copy of Svelte for testing in-development stuff)
• StackBlitz will be around for the forseeable :)
• Projects that need to download npm packages (i.e. the Kit REPL) would need to do so via StackBlitz's npm proxy, so there is a dependency. It might involve an API key; as yet unclear

I think this makes a lot of sense for us; I'm pretty sure this is the future of interactive tutorials.

---

Pros

• Full SvelteKit support, including e.g. HMR
• Corollary: we could build a SvelteKit tutorial. People fucking love the Svelte tutorial but it's unclear how we could make something similar for Kit without something like WebContainers
• Much smarter editor, including e.g. TypeScript support
• More stuff works (npm packages that are tricky to work with in the REPL, plus the REPL doesn't let you try out e.g. preprocessors)
• Less for us to maintain
• I often use the REPL to create mini apps for things I need in the moment, like this one — imagine being able to build and deploy prod-ready versions right from the REPL

Cons

• Currently Chrome-only, which feels like something of a dealbreaker
• It's pretty fast to start up, but the Svelte REPL is massively faster, partly because it has to download way less stuff (though on the flip side, the REPL has to rebundle your entire app, which is much slower. 1 point for the REPL, n points for WebContainers)
• Integration takes work
• Unclear how much control we would have over the UI etc
• StackBlitz could disappear in a puff of smoke

General questions

• Is this a product or a service? Would the REPL be tied to their servers? Would we need API/license keys or whatever?
• Would it be possible for people to run the REPL locally with a local copy of the Svelte compiler?

I'd like to hear more about this npm proxy. What is this doing, exactly? Will its behavior be documented and will it be open source?

Expecting browser support issues to be more or less resolved by end of Q1 2022

Not sure this is strictly speaking true. Every browser may have a release version that supports this tech by then but that doesn't mean everyone is running that version. Desktop is less of an issue than mobile, people run around with older versions of safari on their phone quite frequently and for a variety of reasons.

Projects that need to download npm packages (i.e. the Kit REPL) would need to do so via StackBlitz's npm proxy, so there is a dependency. It might involve an API key; as yet unclear.

Does this happen inside the container or outside? Is this is a requirement or could we do our own thing?

In the webcontainer-core faq it says:

Which Node.js version can I run?
Current version we support is 14.6, other versions will be available as we head into General Availability.

What is the ETA on supporting more recent node versions?

Is this open source?
Today no, but the API will be open source to developers at GA.

This is ambiguous, will the code be open source or just the API?

Hi all- cofounder of StackBlitz here! Answering questions from @Conduitry & @pngwn inline below:

I'd like to hear more about this npm proxy. What is this doing, exactly? Will its behavior be documented and will it be open source?

The official npm registry doesn't have CORS enabled which prevents browser clients from directly fetching metadata/tarballs. Our npm proxy just allows us to make requests to the registry browser-side (along with some other perf improvements), and you can see the source under the turbo folders in https://github.com/stackblitz/core.

Expecting browser support issues to be more or less resolved by end of Q1 2022

Not sure this is strictly speaking true. Every browser may have a release version that supports this tech by then but that doesn't mean everyone is running that version. Desktop is less of an issue than mobile, people run around with older versions of safari on their phone quite frequently and for a variety of reasons.

We actually spent a lot of time thinking about this exact problem as we built out WebContainer and ultimately decided for two reasons:

1. Using existing solutions to this problem all require server-side compute, which provides a substantially worse experience, which is especially bad for learners.

2. From a security POV it's easier & more important than ever for folks to be updating their browsers/devices, and we feel it's important to help guide our users in this direction especially with the recent ramp in supply chain attacks.

One option for the sveltekit repl in particular could be to have a "read-only" mode for browsers that aren't up to date. This would be functionally equivalent to what embedding server-side IDEs like codesandbox, glitch, replit, etc currently provide to end users.

Projects that need to download npm packages (i.e. the Kit REPL) would need to do so via StackBlitz's npm proxy, so there is a dependency. It might involve an API key; as yet unclear.

Does this happen inside the container or outside? Is this is a requirement or could we do our own thing?

It's done in the container but you can absolutely do your own thing, whether that's writing JS/bin files to the container itself, or fetching files/tarballs/etc and extracting them to the webcontainer filesystem.

What is the ETA on supporting more recent node versions?

We're planning to have general support for LTS releases, starting with 14 right now. We're currently targeting support for 16 in Q1.

Will the code be open source or just the API?

The webcontainer package we release will be fully open source, still TBD how much of webcontainer's core would go into that package. The parts that don't would be loaded in a cross-origin iframe on our domain, which is required for enabling access to our necessary proxies for npm, git, etc.

Hope these answers help! Let me know if y'all have any other questions :)

Hey @EricSimons. Thanks for answering our questions, especially good to get your thoughts on the browser support situation. For what it's worth, couldn't agree more of server vs client REPLs.

I guess one final question would just be around the timelines on when these APIs and packages would be available; when can we start playing with this? :P

I guess one final question would just be around the timelines on when these APIs and packages would be available; when can we start playing with this? :P

Great question 😄 Technically speaking this API won't be crazy complex for us to put together, so we could likely have the first alpha version by mid-Q1 with a final in early-mid Q2 with full browser support landed.

The main thing that would help us atm is having a good 'design partner' who can provide feedback on the proposed API surface(s), DX, integration, etc. I mentioned to Rich that I think the Svelte community would be super ideal for this as y'all have good taste in DX, and I could see the SvelteKit repl becoming the "gold standard" for how folks create fullstack repls for docs in the same way that the Svelte repl has led the pack for FE.