vue/playground
Vue Playground and Online Editor with a Live Console
Answer a small Vue question in the time it takes to ask it — hot updates, a console beside the running app, real packages, and a link you can hand to whoever is waiting on the answer.
<script setup>
import { ref, watchEffect } from 'vue'
const count = ref(0)
watchEffect(() => console.log('now', count.value))
</script>
<template>
<button @click="count++">{{ count }}</button>
</template>01 platform
Why a playground is the right shape for a question
Not every Vue question deserves a project. Most of them are one component and one assumption you want to check, and the cost of finding out should be seconds.
-
The gap between idea and answer is the product
Type, save, look. Nothing is scaffolded, nothing installs, and no dev server has to be alive for the preview to update.
-
Small does not have to mean single-file
Split the experiment across a component and a composable the moment it stops fitting in one file. A playground that forces one file forces you to change the question.
-
Real packages, not stubs
Pull in VueUse or Pinia and test against the actual library. An experiment against a mock answers a question you did not ask.
-
An answer you can hand over
Send the link. Whoever opens it sees exactly what you ran, which is the difference between a reproduction and a description of one.
02 pipeline
From a question to a running answer
Four moves, none of which involve a terminal. This is the whole loop, and it is why a playground beats a local project for anything under an hour.
-
Open
A Vue project is already there — a component, a mount point and a preview. Nothing to scaffold, nothing to name.
-
Type
Write the thing you are unsure about. Completion and diagnostics work while you do, so obvious mistakes never reach the preview.
-
Watch
The compile runs on save and the preview updates in place. Component state survives where it safely can, so you are not re-clicking your way back to the case you were testing.
-
Share
Hand over the link. The recipient opens the same files in the same state, which is what makes this useful on an issue thread.
03 features
What is in the playground
Everything below is on from the first keystroke — no toggles, no starter to clone, no account first.
-
Hot updates on save
The compile happens client-side in a worker, so the update lands without a page reload and typing never blocks on it.
-
TypeScript with no setup step
Add
lang="ts"and keep going. Annotations are stripped during compilation, so there is no type-check pass to wait on. -
Any npm package
Search, click install, import by name. XCODX resolves through esm.sh and writes a native import map.
-
A hundred starting points
Over a hundred ready-to-run templates, several of them Vue with a router, a store and a UI kit already wired together.
-
Console beside the preview
console.logoutput lands where you can read it without leaving the tab or opening devtools. -
A link that survives
Share the project and it opens as you left it, which is what makes it usable as a bug reproduction rather than a screenshot.
04 deep dive
Watching reactivity actually happen
Most playground questions are really one question: when does this re-run? A loop this short lets you answer it by observation instead of by reading the docs again.
watchEffect shows you its own dependencies. Log inside it and the console tells you exactly which changes triggered a re-run — including the ones you did not expect, which are the useful ones.
ref and reactive behave differently, visibly. Unwrapping in templates, losing reactivity on destructure, the array index caveat — these are five-second experiments here instead of twenty-minute debugging sessions later.
computed caching is observable. Put a log in a computed and read it twice; it fires once. That is a thing you can be told, and a thing you can watch, and the second one sticks.
Effects clean up where you can see it. onScopeDispose and the return value of watchEffect fire on unmount, which is easiest to believe when you have toggled a component and watched the log.
- watchEffect
- dependency tracking
- computed
- cached, observable
- cleanup
- onScopeDispose
- console
- beside the preview
<script setup>
import { ref, computed, watchEffect } from 'vue'
const n = ref(1)
const double = computed(() => {
console.log('computed ran')
return n.value * 2
})
watchEffect(() => console.log('effect', double.value))
</script>05 workflow
A question, answered — with the console watching
One real sequence, from opening the tab to having an answer worth sharing. The console sits beside the app, so nothing here required opening devtools.
- open → Vue playground
- App.vue mounted · 38ms
- [log] user loaded: 3 items
- edit → destructure props
- [Vue warn] props destructured — reactivity lost
- TypeError: cart.total is not a function
- at CartSummary.vue:18
- fix → toRefs(props) → save
- re-mounted · 0 errors · 0 warnings
-
console.log lands in view
Logs, warnings and errors appear next to the running app rather than in a panel you have to remember to open.
-
Throws name the component
A runtime error reports the component and the line, so the search starts in the right file rather than in the whole project.
-
Warnings arrive while you are still looking
Vue's own dev-mode warnings surface in the console beside the app, at the moment the mistake compiles, not after you have moved on.
-
The answer is portable
The link opens the same files for whoever you send it to, which turns a private experiment into something you can put on a thread.
06 deep dive
When something throws
Running code is only half of it. The half that decides whether an hour is productive is what happens in the seconds after something breaks.
The error is attributed. A throw carries the component that raised it and the line in your source, because a stack trace through a render function helps nobody.
Reactivity is inspectable. watchEffect and a console.log are usually enough to see when a dependency actually fires, and the output appears immediately beside the app rather than in a separate window.
State survives where it should. Editing a template or a style keeps the component's state, so you do not have to click your way back to the case that failed on every attempt.
- errors
- component + line
- console
- beside the preview
- recovery
- save to re-mount
- restart
- never needed
<script setup>
import { computed } from 'vue'
const props = defineProps({ cart: Object })
const total = computed(() =>
props.cart.items.reduce((n, i) => n + i.price, 0)
)
</script>07 ecosystem
One project, many stacks
A .vue file can sit beside a .jsx one and a Python script; the compiler is chosen per file, not per project.
08 languages
Everything the editor understands
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
Using the Vue playground — common questions
Questions about the fast loop specifically.
How is this different from the official Vue SFC Playground?
The official playground is deliberately one file and is excellent at that. This one keeps the same speed but lets an experiment grow into several files, install real packages and use Git the moment it stops being a snippet.
Is it a REPL, or a project?
Both, and that is the point. It opens like a REPL — one component, running immediately — and becomes a project when you add the second file, without an export step in between.
Does state survive a hot update?
Where it safely can. Editing a template or a style keeps component state; changing the script setup block re-creates the component, because pretending otherwise would show you a state that no longer matches your code.
Can I see console output without opening devtools?
Yes. Logs, warnings and errors appear in a console beside the preview. Devtools still work if you prefer them, but you should not need them to read a console.log.
What happens when my code throws?
The error is reported with the component that raised it and the line in your source, and the previous render stays on screen. Fix the line, save, and the app re-mounts in place.
Can I pause execution and step through code?
Your browser's own debugger works on the running app — breakpoints, stepping and the call stack all apply, because this is ordinary JavaScript executing in an ordinary browser rather than a sandboxed interpreter with its own rules.
Does async code work — fetch, timers, top-level await?
Yes, all of it. This is a real browser, so anything a browser can execute executes normally, including top-level await inside <script setup>.
Can I use this to reproduce a bug for an issue?
Yes, and it is one of the better uses for it. Multi-file reproduces a class of bug a single file cannot — anything crossing a composable, a store or a router — and the link opens exactly what you ran.
Do npm packages really install, or are they mocked?
They really install. The package is resolved through esm.sh and imported by name through a native import map, so you are testing against the library rather than a stand-in for it.
Can I keep several experiments side by side?
Yes. Each is its own project with its own files and its own installed packages, and they all persist in your browser. There is no limit tied to a plan and nothing expires after a retention window.
Is there a limit on how long a playground lasts?
No. Projects live in your browser rather than on a server with a retention policy, so an experiment you left open last month is still there.
Does the playground work if I lose my connection?
Once it has loaded, yes. XCODX installs as a Progressive Web App and the compiler runs on your device, so editing, compiling and previewing all keep working offline. Only installing a new package needs the network.
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 the Vue playground
One component running in seconds, and a link to hand over when it does something interesting.