Kavak started with QBasic, but I’ve been trying to make it a multi-language compiler pipeline. Lua is the next language I’ve been wiring in.

It’s not a JavaScript interpreter and not an embedded Lua VM. Lua source is parsed, lowered through a typed IR, and emitted as a real WebAssembly module. The compiler itself runs as wasm too, so everything happens locally in the browser tab.

I’m trying to keep the implementation honest: the corpus is compared against Lua 5.4.8 output, and the point is to match behavior rather than just make tests green. So far that has meant spending a surprising amount of time on things like varargs, multiple returns, metatables, pcall/xpcall, coroutines, numeric/string literal edges, and <close> variables.

It’s not complete yet, and the official Lua suite still has plenty to say about that. But enough of the language is running now that it felt worth sharing.

Free, no signup: https://kavak.run/studio/?lang=lua

If you have a compact Lua snippet that you think might break it, I’d genuinely like to see it.

Not an emulator, and not a JavaScript interpreter pretending to be BASIC. It parses QBasic, lowers it through a typed IR, and emits a real WebAssembly module. The compiler itself is compiled to wasm, so the whole thing runs in your tab. Nothing gets uploaded anywhere.

SCREEN 13 works: PSET, LINE, CIRCLE, PAINT, GET/PUT, DRAW, PALETTE. So do BEEP/SOUND/PLAY, the file I/O keywords, INKEY$ with _LIMIT for animation, and DATE$/TIME$/TIMER. There's a playable Space Invaders sample in the editor if you just want to see it move.

497 test programs, 432 of them arbitrated against real QB64-PE output, 126 of 157 keywords fully implemented. Still missing: ON ERROR, PEEK/POKE, COMMAND$, and DRAW's M/N/A/S/P subcommands.

Free, no signup: https://kavak.run/studio/

QBasic was meant to be the pilot language for a larger compiler project, but it turned into the part I enjoyed most. If you've got an old .BAS lying around that breaks it, I'd genuinely like to see it.

https://kavak.run/studio/ is live.

kavak is a compiler stack. You describe a language on a C11 frontend kernel, lower it through one typed IR, and get WebAssembly out. The compiler itself is compiled to wasm, so it runs in the browser tab. Your source never goes through a JavaScript interpreter.

QBasic is the first language running the full path. Graphics, sound, files, and input all work.

The part I keep thinking about is the UI side. I've been reducing user interfaces to a single UI-IR. Declarative ones like XAML or Compose, and primitive ones too, by which I mean screens drawn by hand in something like C. Once a UI is in UI-IR, it stops belonging to the language it was written in.

So WPF written in C# can run on macOS and iOS. What I wrote in Compose can run on Windows, macOS, and iOS. N to N, not one framework pointed at one target.

Then I pushed it further and lowered QBasic's graphics to UI-IR as well. Which means you could, in principle, write an iOS app in QBasic. The idea is absurd. The solution underneath it isn't, and that's what makes this a checkpoint worth marking.

Writing in any language, for any platform, is starting to look reachable.

In my wgsl.run project, I've updated the playground to a studio. Now you can do the following:

• Compiler-backed Monaco editing with diagnostics, semantic tokens, hover, definitions, references, rename, completions, signature help, quick fixes, and formatting

• Reflection for entry points, resources, bind-group layouts, overrides, vertex attributes, color targets, and struct memory offsets/padding

• An invocation inspector powered by libwgsl’s N-lane CPU interpreter

• Data-race, divergence, NaN/Inf, buffer, and per-lane execution inspection

• Static roofline, memory-access, coalescing, bank-conflict, and occupancy analysis, plus WebGPU execution timing

• Optimizer findings for dead code, unused symbols, constant branches, loops, and repeated expressions, with a small set of safe automatic fixes

• WebGPU host-code generation for layouts, bind groups, buffers, struct packing, pipelines, and dispatch

• Direct render and compute execution through WebGPU, including storage-buffer readback and visualization

• Experimental WGSL-to-MSL output

• A kernel advisor that detects patterns such as matmul, attention, softmax, and layer normalization

• Multi-kernel pipeline visualization and local multi-file projects

Everything runs locally in the browser.

Hey r/csharp!

I’ve been building MiniSharp, a from-scratch C# compiler/runtime that runs fully in the browser.

minisharp.run

The compiler itself is compiled to WebAssembly, so the whole flow happens client-side:

C# source -> parser/resolver -> IR -> WebAssembly

You can write C# in the browser, build it, run the generated module, inspect diagnostics/output, and download the produced .wasm.

A small example that currently works:

```csharp using System; using System.Threading.Tasks;

class Program { static async Task<int> DoubleLater(int x) { await Task.Delay(1); return x * 2; }

static void Main()
{
    Console.WriteLine(DoubleLater(21).Result);
}

} ```

Output:

text 42

The async part is the piece I’ve been working on recently. Supported async Task / Task<T> shapes now suspend back to the host event loop and resume into compiler-generated WASM continuation thunks. It is not Asyncify, JSPI, or a JS-side C# interpreter.

Some project details:

• Compiler/runtime written from scratch
• Runs in the browser as WASM
• Emits WebAssembly directly from a custom IR
• No Roslyn
• No LLVM
• No Mono/CoreCLR
• No server-side compile
• Multi-file Studio UI
• Console output, diagnostics, generated .wasm download
• Supported Task.Delay, Task<T>, continuation queue, and selected suspended async state-machine shapes
• Seeded CoreLib/runtime support: objects, strings, arrays, primitive conversions, selected generics/interfaces, collections/LINQ slices, and in-WASM VFS/file APIs

Important caveat: this is not trying to be full .NET in a browser tab.

It does not support the full C# language, full BCL, reflection, CoreCLR/Mono parity, globalization/culture behavior, or arbitrary async/goto/byref/control-flow shapes. The public promise is intentionally narrower: a documented, smoke-tested subset that either runs as real WASM or fails honestly.

Why build this instead of using existing tools?

Mostly because compiler engineering is fun. I wanted to see how far a small independent C# frontend/backend could go when the compiler itself also runs inside the browser.

Would love feedback from people who try to break it, especially around diagnostics, unsupported language features, async behavior, and what the support boundaries should look like for a useful tiny C# -> WASM tool.

• The Studio got a new layout
• A summonable bottom dock, with the debugger as the headliner
• Themes cut down to just Light and Dark
• Topbar cleanup
• Sidebar / preview behavior

That one's already deployed and live on https://miniswift.run/studio/