Author here! Should be all good now, turns out the rate limiter was a bit overzealous

Nice project, thank you for working on it. I was trying to figure out the architecture, and I understand that it runs a Deno VM to execute JS on the backend?

I was working on something similar, but for JVM backends [1]. And it seems there are a lot to learn from your project. For example, I'm using GraalVM that executes JS on the server. But I have to compile JS to WebAssembly because otherwise it produces a lot integration issues on the backend. Do you do the same?

[1] https://github.com/emeraldpay/double-view

▲

skiniks 4 hours ago | parent [-]

Thanks for checking it out! rari uses V8 (via deno_core bindings) embedded directly in the Rust runtime, not a full Deno VM. We execute JavaScript directly on V8 without compiling to WebAssembly.

The key is that deno_core provides clean Rust bindings to V8's C++ API, which lets us run JS/TypeScript with minimal overhead. We handle module resolution, imports, and the React rendering pipeline all in Rust, then execute the actual component code in V8. No WASM compilation step needed.

Your JVM project looks cool! The GraalVM → WASM approach makes sense for JVM integration. We avoid those integration issues by keeping everything in the Rust/V8 ecosystem. The tradeoff is we're tied to V8, but we get native performance and direct access to V8's features.

	▲	splix 2 hours ago \| parent [-]
		That may sound strange, but it turns out I don't use WASM as well. Last time I touched this part was ~8 month ago, and WASM was just one of the experiments, and I forgot about this. Just remember it was hard to find a right approach initially, on how to execute JS without NodeJS environment. But with a right set of polyfills it works now. Anyway, I see we have a bit different approaches on how to handle JS part, and I could get some ideas from that.