4 ms·
Hey HN, Dynaboard founder here. Sharing a bit more about how we built Dynaboard, since I think this audience will appreciate it. More will be shared in future b
by alexkern 5y ago
Hey HN, Dynaboard founder here. Sharing a bit more about how we built Dynaboard, since I think this audience will appreciate it. More will be shared in future blogs :)
Multiplayer: We used the YJS project (https://github.com/yjs/yjs https://github.com/yjs/yjs) as the baseline for our multiplayer system. We created a thin harness around the client and ended up implementing our own server-side architecture to handle relaying between the various WebSocket servers. More on how we do this soon.
WebAssembly: Rather than running your custom code in an iframe, we run it inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS). This approach gives you synchronous access to most of the DOM APIs without sacrificing safety. We do some fancy ES6 Proxy management to implement the FRP-like data binding system inside the VM. In production, the browser runs the project's precompiled bytecode. In the future, we plan to support other languages with a similar architecture (Python via Pyodide, Rust, Go, etc.).
Code editing: We use Monaco, the same editor that VS Code uses. We've had to create a handful of custom extensions, including a few custom language servers, to get it to be aware of the VM environment. I'm a vim-er so we will definitely have a vim mode.
- alexkern 5y agoJust for fun, some of our engineers (including swimmadude66) spun up this Hacker News look-alike[1] app in Dynaboard that hits the HN API. [1] https://dynaboard.com/images/screenshots/DynaHacker_News.png https://dynaboard.com/images/screenshots/DynaHacker_News.png
- cxr 5y ago> we run [your custom code] inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS). I'm curious about why. Is sychronicity the only reason? (And is it really worth it? `await` makes asynchronous code paths pretty unobtrusive.) Mirrors[1][2] are pretty interesting. (Not sure that I agree that compile-to-WASM makes for JS-in-JS. WASM isn't JS. Why do people keep conflating them?[3]) 1. <https://bracha.org/mirrors.pdf https://bracha.org/mirrors.pdf> 2. <http://www.wirfs-brock.com/allen/posts/228 http://www.wirfs-brock.com/allen/posts/228> 3. <https://news.ycombinator.com/item?id=29754432 https://news.ycombinator.com/item?id=29754432>
- conradev 5y agoI imagine that part of it is for security. Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them: https://www.figma.com/blog/how-we-built-the-figma-plugin-system/ https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...
- cxr 5y ago> I imagine that part of it is for security. Sure, that much is clear. But we're discussing it in contrast with other security-preserving approaches. "For security" only really makes sense we were asking, "Why do any of these things at all?", but we're past that. What we're asking is "Why this thing specifically?"—especially where that thing is expensive. > Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them First: to reiterate, JS-in-WASM is not JS-in-JS. Secondly: Mirrors, notably, are not among the approaches they evaluated. I advocated for an evaluation of a similar Mirrors-based approach in the HN thread at the time that the Figma post was published: <https://news.ycombinator.com/item?id=20770105 https://news.ycombinator.com/item?id=20770105>
- garciasn 5y agoWe’re signed up for the alpha to do some testing. Any plans to support BigQuery?