Inside the Multilingual Playground: How the Browser, WASM Runtime, and Language Packs Fit Together

In a recent article, I explored how a human-language-first programming language can move from multilingual syntax to multilingual runtimes using WebAssembly. This post goes a level deeper and opens the hood on the browser playground that makes this possible.

• Project repository
• Online playground
• Language core

If you have the playground open while reading, you can map each section here to something you can actually click, run, or modify.

---

The three layers of the playground

At a high level, the playground is three things working together:

1. Browser UI
   
   A simple HTML/CSS/JavaScript interface with:

   • A code editor
   • A language selector (English, French, Spanish, …)
   • A “Run” button
   • Panels for program output and intermediate representations

2. WASM runtime
   
   The multilingual interpreter, compiled to WebAssembly, plus a few helper pieces that make it easy to call from JavaScript. The interpreter does the heavy lifting: lexing, parsing, building the AST, and evaluating the program.

3. Language packs
   
   Data that describes how each human language maps to the shared semantic core: keywords, operators, sometimes punctuation, and eventually error messages. Each pack is configuration, not a fork of the runtime, which is key to keeping the system maintainable.

You can think of it as: HTML talks to JS, JS talks to WASM, WASM talks to your code — and language packs change only the “accent”, not the meaning.

---

From source code to execution in the browser

When you write a program in the playground and hit “Run”, the flow is roughly:

1. Collect source and language choice
   
   The UI grabs the text from the editor and the selected human language (for example, fr or en).

2. Call into the WASM module
   
   JavaScript passes { source, language_id } into an exported WASM function via WebAssembly.instantiate bindings. Internally, the WASM module sees raw bytes and a language identifier, not “French” or “English” in any special way.

3. Lexing and parsing with language packs
   
   Inside the WASM runtime, the lexer and parser look up the right keyword mapping for the chosen language pack. si, wenn, and if can all map to the same conditional AST node, regardless of the surface language.

4. Build the unified AST
   
   The parser produces a single, language-agnostic AST. From this point on, the runtime is completely indifferent to which human language you wrote in.

5. Evaluate and send results back
   
   The interpreter evaluates the AST, captures outputs and errors, and sends structured results back across the JS/WASM boundary. The browser then renders them in the output panel.

All of this happens inside a sandboxed environment in your browser, which is why learners only need a URL to experiment.

---

How language packs plug into the core

The language packs are what make the playground multilingual instead of just another monolingual WebAssembly demo.

A language pack typically contains things like:

• Keyword mappings: if, else, while, etc. in a given language mapped to internal tokens or constructors
• Logical operator names (and, or, not)
• Literal conventions if they differ (for example, decimal separator)
• Metadata like language name and code

In practice, the runtime does something conceptually like this:

• Look up language_id in a registry of packs
• Build lexer/parser tables using that pack’s tokens
• Produce the same internal AST no matter which pack you used

Because the packs are configuration, adding a language is “just” adding some new lines and wiring it into the registry rather than forking the interpreter. That design is what makes it realistic to experiment with 10+ human languages without drowning in maintenance.

A nice side effect: the playground can show you the same program rendered in different surface syntaxes while keeping the underlying semantics identical.

---

Error handling and diagnostics today (and tomorrow)

Error handling is where multilingual runtimes get interesting.

Right now, the playground leans on a simple but powerful separation:

• The core interpreter produces language-agnostic error codes and structures.
• The browser UI is responsible for displaying those errors to the user in a friendly way.

That design opens the door to more advanced diagnostics:

• Localized error message catalogs keyed by error code
• The ability to show errors in the same human language as the source
• Potentially toggling the language of diagnostics without rerunning the program

For example, the same parse error could be rendered in French and then in English just by swapping the message catalog, while the underlying error object stays the same. A WASM-based playground is a convenient place to prototype this because everything is already running in the browser and can react in real time.

---

Deployment and extensibility

From a deployment perspective, the playground is just static assets:

• HTML and CSS for the UI
• JavaScript glue code
• The compiled WASM binary
• JSON or similar files for language packs

That makes it easy to host on GitHub Pages or a personal site, as in the current playground. Once the interpreter is compiled to WASM, the same core can also be reused in other contexts: online textbooks, documentation, or even IDE extensions via a WASI environment.

There are several natural directions to extend this setup:

• More language packs, including scripts and writing systems that stretch assumptions about keywords and layout
• Richer visualizations of the pipeline (for example, showing WAT or internal AST alongside your code)
• Embeddable widgets where the multilingual runtime appears inside tutorials and interactive learning material

If you try the playground and experiment with new languages or ideas for diagnostics, I would love feedback and contributions in the repository.

• Project repository
• Online playground
• Language core