I love reading technical blogs, and Fabien Sanglard’s are some of the best out there https://fabiensanglard.net/

also the simple design of the website makes it great

When I was doing presentations for university projects as a student, I used your articles as references, very useful!

Happy to hear :)

Hi, I like it, maybe u can try to add SEO tags so new pages can get indexed

Is it the same for Vercel? It's even more expensive there. Scary

I tried to build a small web demo with Rapier too https://github.com/iErcann/NotRoblox (no rust)

What I like : - Good documentation compared to AmmoJS (you need to read pybullet)

- Recent

- You can run it server side (Node) & client side (Browser), here I'm running it server side but it's possible to do both and implement client side prediction + reconciliation

- Small bundle (AmmoJS was like 2 MB?)

> What I like : - Good documentation compared to AmmoJS (you need to read pybullet)

On the Rust side, the Rapier docs are out of date AFAIK. Fortunately I'm stuck on the previous version so it's not so bad.

Nice idea

Cool project, when you add multiplayer to a simple game without any game engine and want to actually do it right (CSP, interpolation, lag compensation) it gets technical really fast

I spent months trying to make a CS like in Three.js, then I was wondering myself if it was actually worth it

I could just have used a random game engine that can export to WebGL with wasm even if the first loading was bigger, people wouldn't even notice nowadays

WebGPU is coming out if I'm correct, I wonder how good will web games run now

Could check this out https://github.com/hexops/mach-gpu

That's WASM based which puts it at a disadvantage to a javascript based renderer.

Really? My understanding was that WASM support was good these days. And performance is a key issue with games

JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers can do, but it's game of catch up with the performance of javascript. Or if you want to share code between a native version of the game and the web version WASM may be good. Performance should not be the reason you pick WASM.

> JavaScript will typically have better performance than WASM.

That's a very - erm - interesting opinion which I haven't seen elsewhere yet ;)

IME, asm.js can achieve similar performance as WASM, but not 'idiomatic' JS.

Calls from WASM into JS are fast nowadays, but they are still an optimization barrier, doing this frequently (e.g. hundreds-of-thousands times per frame) is neither recommended, nor needed (and that's about the only situation where I can imagine that pure JS might outperform WASM - and IIRC I've seen some poorly built benchmarks which showed exactly this and which then claimed that "JS is faster than WASM").

(to be clear: JS and WASM performance is closer than most people think, but JS consistently outperforming WASM is the same sort of myth like "Java is faster than C++ because a JIT has more optimization opportunities" - that might be true in theory, but not in the real world outside some fabricated benchmarks).

“Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,”

https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...

I would like to see this done with JavaScript that is an actual game or application. A gameboy emulator is a virtual machine and is not heavy on IPC with the DOM. Measuring a C++ program compiled into JavaScript (C virtual machine) doesn't seem representative either.

The paper more shows that if you are building a virtual machine in the browser you should use WASM. I agree that is a sensible choice.

The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function.

Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"

The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble.

So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions.

My point is that if you are making a big chunk of JavaScript already there is a benefit to just doing most of everything else with JavaScript if you can get away with it. I'm not trying to claim that in all circumstances WASM will be slower and I will encourage people to check for themselves, but I will stand behind the claim that performance should not be the reason you choose to make your web application with WASM.

> performance should not be the reason you choose to make your web application with WASM

This I can mostly agree with, but it's a slightly different take than "JS is faster than WASM" though ;)

The marshalling for 'non-trivial types' (like strings or data structures) can indeed be a performance problem, but quite often one can get away with just passing numbers between the JS and WASM side. I'm actually a bit disappointed that WebGPU turned out so 'object-oriented' (e.g. most WebGPU objects are actual Javascript objects instead of 'number-handles'), which means that a lookup-table needs to be maintained on the JS side (I think that's what the externref proposal is supposed to solve).