WebAssembly from Scratch: From FizzBuzz to DooM

Post by mamcx » Wed, Jul 14, 2021, 3:19 PM UTC

flohofwoe wrote: post #10

recursivedoubts wrote: post #2

I can't tell if the lack of strings and DOM API interop in web assembly is on purpose or not. If it is on purpose, what an absolutely diabolical way to ensure javascript language dominance in the browser: give people a way to port their language to the browser, but make it incredibly difficult to do anything.

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Ja…

Post by pjmlp » Wed, Jul 14, 2021, 3:30 PM UTC

mamcx wrote: post #32

flohofwoe wrote: post #10

Earlier quoted context omitted.

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Ja…

>What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.

Post by pjmlp » Wed, Jul 14, 2021, 3:31 PM UTC

HideousKojima wrote: post #17

recursivedoubts wrote: post #2

I can't tell if the lack of strings and DOM API interop in web assembly is on purpose or not. If it is on purpose, what an absolutely diabolical way to ensure javascript language dominance in the browser: give people a way to port their language to the browser, but make it incredibly difficult to do anything.

It's also still missing proper garbage collection, meaning languages like C# have to include basically the entire runtime if you compile to WebAssembly. This is a major part of why Blazor apps in .NET 5 are ~2MB for a simple "Hello World" (closer to 8MB if you use the AOT compilation options in the .NET 6 preview).

Post by AlecMurphy » Wed, Jul 14, 2021, 3:37 PM UTC

Post by asiachick » Wed, Jul 14, 2021, 3:41 PM UTC

djhworld wrote: post #31

devwastaken wrote: post #25

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performan…

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…