Deno 2.9

For Windows, it was a bit less dramatic, but WebView2 is controlled by Windows Update in Windows 10, Some players have it, some players don't. And requiring windows 11 and up is a very unpopular choice. Maybe could have been solved by vendoring it but also not super clean.

I look forward to give it a try again, when Steamworks Linux runtime 4.0 comes around, and less people are still using Windows 10.

https://explodi.tubatuba.net/2025/09/26/using-deno-as-my-gam...

I also asked claude to give me a 1-paragraph summary of how our stack works. Anyway, if you have more questions i'm happy to answer e-mail (check my profile)

Robotic text below:

The whole thing is TypeScript end-to-end, run by Deno, which acts as the glue. In the browser, there are just two pieces communicating over a native WebSocket: a React front end bundled by Vite—Deno runs Vite for the development server and hot reload—and a Deno back end that owns the simulation.

The simulation runs on a tick loop, with each tick representing roughly one in-game day and taking about one second of wall-clock time. The client sends small command events such as `newBuilding` and `bulldoze`. The server processes each tick and broadcasts all resulting state changes in a single batched frame. This makes the client essentially a renderer of authoritative server state, with a full resynchronization whenever it reconnects.

Under the hood, the simulation distributes heavy workloads—including demographics, taxes, and housing markets—across Web Workers. These workers coordinate through a shared SQLite database used as a cross-thread bus, allowing the game to simulate tens of thousands of citizens.

The 3D layer uses Three.js with WebGPU, a WebGL2 fallback, TSL shaders, and batched draw calls. It runs imperatively in its own `requestAnimationFrame` loop inside one large component, deliberately avoiding React Three Fiber. React manages only the 2D HUD and menus layered on top, keeping the performance-critical rendering loop entirely outside React’s reconciliation process.

The key point for prototyping is that the browser application—the client plus a local server connected over WebSocket—is the entire game. The desktop builds are simply thin native shells around the exact same application. On macOS, the shell uses Tauri with Rust and the operating system’s WKWebView. On Windows and Linux, it uses Electron with bundled Chromium.

Each shell launches the server, compiled into a single self-contained binary using `deno compile`, as a sidecar process. It then finds an available localhost port and points its webview at the bundled client. This means the game can be built and iterated entirely in the browser, with native packaging added only at the end.

but the project is structured the same as another public domain project I've built, and I just checked to make sure it has the same issue. I've gone ahead and made that project public so you can give it a try[0].

but, just to be clear, I don't think the message is wrong? The Node version on this machine is out of date. And when comparing the deno.lock file to the bun.lock file, I can see that the deno.lock has a slightly newer version (8.1 vs 8.0) of vite. So I think the message could be correct and is just telling me to update my version of Node, which is perfectly reasonable. It's just the discrepancy between not needing the newer version of vite/node on bun while invoking an error using deno. Feels like I should have either gotten perfectly matching versions, or error messages (with commands) to update node.

in any case, if you're still interested in seeing the error yourself, my steps were: 1. clone the repo 2. run deno install 3. run deno task dev

[0] https://gitlab.com/cynic-devs/magnitce-code-example

I've gone back and forth on this point over the years.

Yeah, Node compat has probably affected the rest of the product. I imagine at some point they (or their investors) freaked out because adoption wasn't happening. And the reality is it really doesn't matter if your product is better when nobody is using it.

In retrospect I think it would have been a better decision to target Node compat from the start like Bun did. An impossible option at the time given Deno started trying to make something different from Node.

Or maybe the problem was simply they couldn't afford low adoption after having investors on board.

Can we please not turn Deno into junk? If you do the above -- what's the point of Deno?

Once you bolt everything on like that you might as well just use Node.

Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...

Maybe reality isn't represented by the git logs, but according to them, you appear to have composed, reviewed and merged 131 commits affecting 58 files and 6000 lines -- a task that you say amounts to "replacing the engine while driving" -- in the span of one week.

If that's accurate, of course your reliance on AI is at fault here. It invites you to mistake velocity for quality and conflate test satisfaction for completion.

Without AI, this effort would likely have taken much longer and an experienced team would have approached it with due meticulousness, being especially stringent in review. Absorbed in it, the work would have weighed on their unconscious while they slept, with "Ah shoot, did I consider XYZ?" moments striking them in the shower. Ideally, familiar with the specific contributors (i.e. you) and their style of work, the reviewer who later consider merging the work would have ideas what to watch out for and would spend extra time looking at the details you might not have fully considered. It's a whole decades-matured craft practice that can do a pretty good job of making sure that a refactor of this scale doesn't land in main too broken.

And while that version still probably wouldn't have been entirely flawless either, or might never have even been attempted because of its greater calendar and attention burden, that doesn't mean that using AI wasn't responsible for why and how this version is broken.

This is exactly how AI makes things worse and why many people are wary of relying on third-party projects that embrace it too blithely. If you're going to use it, that's great, and maybe it will help you keep landing big features more quickly than otherwise -- but at least accept responsibility for the tradeoffs that you're inviting when you do so.