About MOO Academy

What happens when you run code?

The web host serves the site’s pages, JavaScript, WebAssembly assets, and prepared worlds. Parsing and MOO execution happen on your device. Your exercise code runs locally; it is not submitted to a remote MOO server for execution.

1. Parse. The editor uses a Tree-sitter MOO grammar, loaded through WebAssembly, to identify syntax problems.
2. Execute. The educational JavaScript runtime checks the selected profile and evaluates supported code in a browser Web Worker, keeping the interface responsive.
3. Inspect and save. The runtime returns output, diagnostics, a return value, and a world result. Accepted world changes become the current world and are saved locally.

Code and Eval share the current world. The active workspace reuses a worker to reduce repeated startup costs. Stop terminates the active run and discards its uncommitted changes. A normal MOO error or a tick limit can retain changes made before the failure, so always read the feedback.

Parser and runtime limitations

A syntax check is not a promise of execution support. Tree-sitter recognizes the shape of code; the runtime separately decides whether its features are implemented and allowed in the selected LambdaMOO or ToastStunt profile. For example, maps belong to the ToastStunt profile, and fork is unsupported by this runtime.

The bundled grammar also has differences from native MOO parsing. It reads verb bodies, not whole native database dumps or interactive .program sessions. Some valid native spellings are not accepted: use 325.0 and 0.0325 instead of the shorthand 325. and .0325. These are limitations of the bundled parser, not new MOO language rules.

The runtime implements an educational subset. Full permission enforcement, command dispatch, a native task scheduler, WAIFs, anonymous objects, multiple inheritance, and native multithreading are outside the current implementation. Regex support also differs from native server engines. suspend() waits at most five seconds here; that cap is specific to this learning environment.

File and connection exercises use virtual state. Network requests and process-related builtins use configured fixtures rather than contacting arbitrary services or launching programs. SQLite exercises run a local SQLite engine compiled for the browser. Builtin notes in Reference explain which behavior is implemented, limited, or simulated.

Common Packages preserves imported ToastCore utility source. Retaining a verb’s source does not make every dependency executable in the browser. Lessons that need native services label their real-server exercises separately. The runtime’s compatibility notes describe its supported surface.

How saving and loading work

A world is a collection of objects, properties, verbs, and supported virtual host state. The runtime serializes it as a versioned JSON snapshot, including its profile and verb source. Loading validates the snapshot and compiles supported verb source; it does not run those verbs just because a world was opened.

The app stores snapshots and code drafts in IndexedDB, your browser’s local database. Progress and preferences use local browser storage too. Each track and each named sandbox has its own world for each profile. Drafts are separate from worlds, and completion progress is shared between profiles.

Code drafts save as you edit; Eval text saves when evaluated. Switching workspaces saves pending work first. One tab at a time owns write access, which prevents competing tabs from overwriting each other’s worlds. Watch the save status if storage fails or another tab is editing.

Your saves belong to this browser and this site address. There is no account-based cloud sync. Clearing site data, changing browsers or devices, or using a different site address can leave you without access to those local saves. Use Export world and Download drafts for copies you control.

Import world validates an exported snapshot and asks before replacing the active world. Choose the same profile used for the export. Academy JSON snapshots are not native LambdaMOO or ToastStunt .db files. Download drafts produces a separate JSON recovery file; copy its code back into an editor rather than importing it as a world.

Load lesson starting world restores a lesson’s prepared state; Reset track world restores the beginning of a track. These actions ask for confirmation and keep code drafts and progress. Following lessons in order normally means keeping your current world.

Built with open-source projects

• MOO Academy — this website’s source: interface, lessons, persistence, import tools, and tests.
• moo-in-javascript — the TypeScript/JavaScript educational runtime, world model, profiles, workers, and snapshot support.
• tree-sitter-moo and Tree-sitter — the MOO grammar and parsing system, used in the browser through web-tree-sitter and WebAssembly.
• sql.js — SQLite compiled for JavaScript/WebAssembly, used by the runtime’s database exercises.
• ToastCore — the original core database behind the imported Common Packages utilities.
• toaststunt-db-extractor and moo-code-graph — tools used to extract and analyze the native database while preparing Common Packages.

Development and verification use Node.js, its test runner, and Playwright browser tests. Learners do not need these tools installed. The project repository includes setup instructions, licenses, and third-party notices.

Ready to explore the wider MOO ecosystem? Visit Resources for native servers, documentation, tutorials, and community links.