Hey HN! Esolang Park is an online visual debugger interface for esoteric programming languages, that I've been working on for the past few months. For every supported language, Esolang Park provides the powerful Monaco code editor, syntax checking, debugging functionality and a visualisation of the runtime state. The core is language-agnostic - a "language provider" only needs to implement the esolang's parser, interpreter and visualisation UI (and some other little stuff).
Apart from trying to boost DX for esolangs, the idea is for this to grow into a platform where people can discover and play around with a variety of esolangs without leaving the browser. That's quite far away though - the project is quite early in development and currently only has 5 languages (Befunge-93, Brainf*ck, Chef, Deadfish and Shakespeare). Some features like non-debugging execution mode (0ms interval) are missing too.
Currently the entire source code[0] (core + language providers) is written in TypeScript and React. Esolang code execution happens in a web worker. I'm planning to add support for WASM-based language providers for better performance, particularly for non-debugging execution. There's also a wiki[1] containing a description of the core design and a guide for implementing and contributing new language providers.
Looking to hear some feedback on the idea and current implementation - bug reports are welcome too!
[0] https://github.com/nilaymaj/esolang-park
[1] https://github.com/nilaymaj/esolang-park/wiki
> the bottleneck in performance turns out to be the React frontend. It is the time taken by the React frontend to render execution updates that dictates the fastest possible execution speed.
Why have React re-render each time execution updates? I don't think a user could make use of an updated visualization more than a few times per second, so it seems possible to re-render at a fixed rate (or at least capped, e.g. via 'debouncing' which ever function triggers the state update) while letting execution run relatively independently.
Also: could you say more about what kinds of the things the visualizer is capable of showing? I checked out the examples for each language and can get some sense of its range from that but I'd be curious to know more. (For example, when I was working on a program state visualizer I opted to provide visualizations of particular data structures, e.g. lists, trees, tables, maps etc.)