svelte-sandbox.landing Open editor

svelte/sandbox

Svelte Sandbox for Multi-File Application Development

Build a Svelte application the way you would locally — components, shared rune modules, routes and styles in a real folder tree, with packages, a terminal and Git — on whatever machine you are sitting at.

Open the workspace See the editing surface
editorMonaco + .svelte
modules.svelte.ts state
packagesnpm panel
vcsisomorphic-git
project
src/
  lib/
    components/  Card.svelte  Nav.svelte
    state/       cart.svelte.ts  session.svelte.ts
    utils/       format.ts
  App.svelte
  main.ts
package.json
15 files

01 platform

Where a Svelte app outgrows a single component

Svelte starts smaller than most frameworks, which is its appeal — and it means the thresholds arrive quietly. These are the four that a one-file editor cannot follow you past.

  • The second component

    A .svelte file is a component by definition, so the moment there are two, there is a project. Importing one from another needs a real path rather than a tab.

  • The first shared rune module

    State that two components read belongs in a .svelte.ts file. That extension is what tells the compiler to look for runes, and it only makes sense in a tree that has directories.

  • The first client route

    Svelte without SvelteKit still needs navigation. A router package and a routes module are separate files by nature.

  • The first style you want to reuse

    Component styles scope automatically, which is why a genuinely shared stylesheet is a deliberate separate file rather than an accident.

02 deep dive

Completion that understands a .svelte file

A .svelte file is markup, script and style in one document, and each part wants different completion. An editor that treats it as HTML with extra tags is an editor you fight.

Components resolve from your imports. Type <Ca in markup and the editor offers Card because it read the import statement, then completes the props the component declares through $props().

Runes complete as compiler symbols. $state, $derived, $effect and $props are suggested where they are legal and not where they are not, because they are syntax rather than functions in scope.

Block syntax is understood. {#if}, {#each}, {#await} and {#snippet} are Svelte's own control flow, and they close, indent and complete as such.

Rename crosses the markup boundary. Rename a prop and both the $props() destructuring and every binding that passes it follow, which only works with the whole project loaded.

components
from imports
props
typed via $props()
blocks
{#if} {#each} {#snippet}
engine
Monaco
List.svelte
{#each items as item (item.id)}
  <Card
    title={item.title}
    onselect={() => open(item)}
  />
{:else}
  <p>Nothing here yet</p>
{/each}

03 workflow

From one component to a committed project

No npx sv create, no dependency install, no dev server. This is the whole thing, start to first commit.

session
  • new project → Svelte
  • src/App.svelte, src/main.ts
  • new file → lib/state/cart.svelte.ts
  • runes enabled by extension
  • npm i svelte-routing
  • resolved via esm.sh · import map updated
  • git init && git commit -m "scaffold"
  • [main a92f10c] scaffold · 15 files

  • The file extension carries meaning

    .svelte.ts is what enables runes in a plain module. Creating that file correctly is something a tree makes obvious and a single buffer cannot express.

  • The repository is real Git

    Commits, branches and history are genuine Git objects through isomorphic-git. Push to GitHub, or pull an existing repository in and keep committing.

  • It survives the tab closing

    Projects, history and Git objects live in your browser's storage, so reopening is instant and works offline.

04 features

What the workspace gives a Svelte project

The tools below are the ones a Svelte codebase leans on once it is past one component — a Svelte code editor with the navigation a multi file project actually needs.

  • Go to definition across modules

    Ctrl-click an imported component or a rune module and land on its declaration, in whichever file that is.

  • Rename that follows bindings

    Rename a prop or a component and every import and every markup binding updates together.

  • An npm panel

    Search, click install, import by name. The import map is written for you and travels with the project.

  • Real Git

    Stage, commit, branch, diff and read history. Import a repository from GitHub and keep working against its real history.

  • An integrated terminal

    A shell surface over your project files, for when typing is faster than clicking through a tree.

  • SCSS inside a component

    <style lang="scss"> compiles through Dart Sass in the browser and still scopes to the component.

  • Per-project file history

    Restore points and auto-save, so a refactor that went wrong is a click back rather than a rewrite.

  • Everything on the device

    Projects are stored locally and work with no connection. A half-finished experiment stays yours.

05 deep dive

Where components and rune modules belong

Svelte has fewer conventions than most frameworks, which means the ones a project adopts have to be deliberate. These are the three that pay for themselves immediately.

lib/components for anything rendered. A flat components directory stops working around the twentieth file; grouping by feature rather than by type is the split most projects reach eventually.

lib/state for .svelte.ts modules. Shared reactive state is now ordinary exported variables, and filing them together is what stops them being rediscovered as a surprise.

Plain .ts for anything that is not reactive. A formatter or a fetch wrapper does not need the rune-enabling extension, and using it anyway makes the ones that do look unremarkable.

The tree is the documentation. Svelte will not enforce any of this, which is exactly why writing it down in the folder names is worth the small discipline at the start.

components
lib/components
state
lib/state/*.svelte.ts
helpers
plain .ts
entry
src/main.ts
main.ts
import { mount } from 'svelte'
import App from './App.svelte'
import './app.css'

mount(App, { target: document.getElementById('app') })

06 pipeline

How a Svelte project grows here

Four stages, none needing a machine you have configured. This is the argument for a browser workspace over a local one for anything you did not start.

  1. One component

    App.svelte and a mount call. Nothing to configure — where the template starts, and where a single-file editor would also be adequate.

  2. Components that import components

    Split the markup, pass props through $props(). Go-to-definition starts earning its place the moment two files depend on each other.

  3. Shared state in modules

    Move reactive state into .svelte.ts files and import it from anywhere. This is the step that most distinguishes Svelte 5 from Svelte 4, and it needs a real tree to do at all.

  4. Routes and handoff

    Add a client router, commit the history, then push to GitHub or export a zip. What leaves is ordinary source — the same files a local project would have produced.

07 ecosystem

A project that mixes compilers

A .svelte file can sit beside a .vue one and a Python script; XCODX picks the compiler per file rather than per project.

  • React
  • Vue
  • Angular
  • Svelte
  • SolidJS
  • Lit
  • HTMX
  • Vite
  • TypeScript
  • JavaScript
  • HTML
  • CSS
  • SCSS
  • Less
  • Pug
  • Tailwind
  • Bootstrap
  • Vuetify
  • Ant Design
  • shadcn/ui
  • Phaser
  • Node.js
  • Python
  • Java
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • SQL
  • Bash

08 languages

Every language the editor knows

Highlighting and IntelliSense cover 70+ languages. These are the ones XCODX also compiles or executes for you.

Compiled in your browser11

Zero build step. Transform runs on a Web Worker, so typing never blocks.

  • JSX
  • TSX
  • TypeScript
  • Vue SFC
  • Svelte
  • Angular (JIT)
  • SolidJS
  • SCSS
  • Sass
  • Less
  • Pug

Rendered natively8

Straight to the live preview, no transform in the way.

  • HTML
  • CSS
  • JavaScript
  • JSON
  • Markdown
  • Jupyter (.ipynb)
  • SVG
  • YAML

Executed on demand22

70+ languages run through a self-hosted Piston engine. stdout, stderr, images and tracebacks land in the console.

  • Python
  • Java
  • C
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • Lua
  • Scala
  • Perl
  • Haskell
  • Elixir
  • Dart
  • R
  • Julia
  • SQLite
  • Bash
  • PowerShell

09 questions

The Svelte sandbox — common questions

Questions about using this as a working environment.

Can a real Svelte application live here?

Yes. Components, shared rune modules, client routing and scoped styles are the parts a Svelte app is made of, and all four have somewhere to live rather than being flattened into one file.

Does SvelteKit work in the sandbox?

No. SvelteKit's file-based routing, load functions and form actions run on a Node server, and a browser tab has no Node process. A client-side router installs from npm and covers navigation; components you build here move into a SvelteKit project unchanged.

How do I share state between components?

A .svelte.ts module. Declare $state there, export it, and import it wherever you need it — no store, no subscription and no $ prefix at the call site. The file extension is what enables runes in a plain module.

Do .svelte.ts files really compile?

Yes, and getting the extension right matters: an ordinary .ts file will not have its runes compiled. That is one of the more common Svelte 5 surprises, and a real file tree makes it obvious rather than mysterious.

Can I use SCSS or a preprocessor in a component?

Yes. <style lang="scss"> goes through Dart Sass in the browser and still scopes to the component, so preprocessing and scoping compose rather than conflict.

Is the terminal real, or a mock?

It is a working shell surface over your project files. There is no Node process behind it, so it covers file and project operations rather than arbitrary commands — no vite build, because there is no Node to run it.

How big a project can it hold?

Comfortably a real Svelte application — dozens of components, rune modules and their dependencies. The limit is your browser's storage quota, not a plan tier.

Can I import an existing Svelte repository?

Yes, from GitHub, with its history intact. A plain Svelte project opens and runs; a SvelteKit one opens and edits, but its server routes will not execute here.

Can I get my project out again?

Export the whole thing as a zip with its folder structure intact, or commit and push. It is ordinary source from that point on, with no proprietary format in the way.

What happens if I clear my browser data?

The project goes with it, the same way deleting a folder removes a local one. That is the trade for storing nothing on a server, so commit and push for anything you would be unhappy to lose.

Does it work on a tablet or Chromebook?

Yes. The workspace is a responsive web app, so a Chromebook or an iPad gets the same file tree, the same compiler and the same preview a laptop does.

Do I need to install anything to use XCODX Studio?

No. XCODX Studio is a browser-based IDE — the editor, the compilers and the preview all run client-side. There is no download, no package manager to set up and no configuration file to write. Opening the editor is the whole setup step.

Where is my code stored?

In your own browser. Projects, file history and Git objects live in local storage on your device and are never uploaded to a server. That also means XCODX works offline: it is a Progressive Web App, so you can install it and keep coding with no connection.

Is XCODX Studio free?

Yes. The editor, the live preview, the 70+ language runtimes, npm installs, Git and the integrated terminal are all free to use.

Can I use XCODX on a tablet or Chromebook?

Yes. The editor is a responsive web app, so a Chromebook, an iPad or an Android tablet gets the same compilers and the same preview a laptop does — there is no desktop-only build, because there is no build to install at all. The layout adapts to the screen rather than shrinking a desktop UI into it.

Can I export a project or move it to my own machine?

Yes. Export the whole project as a zip with its folder structure intact and open it locally, or commit it and push. It is ordinary source on disk from that point on — no proprietary format and no lock-in, which is also why importing an existing repository from GitHub works the same way in reverse.

Nothing to install

Open a Svelte workspace

A project tree, shared rune modules and version control in under a minute, on whatever machine you happen to be sitting at.

Open the workspace Read the docs