Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly from Scratch: From FizzBuzz to DooM

github.com

Post reply on HN
Print view View original

21–30 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#21

Post by Deukhoofd »

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).

Why would WASM have garbage collection? It's an assembly target, not a runtime. What if languages would want different memory management strategies?

I know it's an existing proposal for WASM, but it feels so massively out of scope. If the issue is having to include runtimes in the WASM binary it might be more useful to think about how we could serve runtimes in a more efficient way.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#23

Post by staticassertion »

Deukhoofd wrote: post #21
HideousKojima wrote: post #17

Earlier quoted context omitted.

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).

Why would WASM have garbage collection? It's an assembly target, not a runtime. What if languages would want different memory management strategies? I know it's an existing proposal for WASM, but it feels so massively out of scope. If the issue is having to include runtimes in the WASM binary it might be more useful to think about how we could serve runtimes in a more efficient way.

I feel the same way. I find it very odd that GC is something that WASM ever intends to think about. If shipping your entire runtime sucks, find a smaller runtime?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#24

Post by sharikone »

Just a point for the first chapters: you are not required to run your own local server (even if things push in that direction)

You can include the wasm as an ArrayBuffer or as a base64 encoded string and hardcode it in the javascript. Now it will run even in a static html.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#25

Post by devwastaken »

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 performantly you'd have to throw it all in a webworker so it doesn't block the main thread. This is one point of contention with wasm because it's not straightforward to render to a canvas/webgl on the main thread from a worker thread. OffscreenCanvas is one workaround but not supported by FF or safari.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#26

Post by singularity2001 »

smichel17 wrote: post #19
Jnr wrote: post #16

Interesting that Firefox by default did not render the fizzbuzz demo correctly by default. I had to click the canvas icon next to address bar and allow the canvas usage. And it did not show a prompt either. It just looked broken by default. Screenshot from Firefox vs Chrome https://i.imgur.com/Af8nTim.png

...Good! The "prompt" permission model is fundamentally broken, because all it does is train you to click through the prompt. The "click the blocking button and turn it off" model is much better. It still trains you to turn off blocking when something is broken. However, crucially, that's only when it's broken . When it's not broken, you just use the site, instead of habitually clicking through the permission prompt…

   >>> all it does is train you to click through the prompt.
no, if I want extra functionality, I click it, otherwise I ignore it. (random page wants my location? nah)

modular blocking prompts were broken, optional prompts are fine

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#28

Post by jjice »

sharikone wrote: post #24

Just a point for the first chapters: you are not required to run your own local server (even if things push in that direction) You can include the wasm as an ArrayBuffer or as a base64 encoded string and hardcode it in the javascript. Now it will run even in a static html.

It's incredible how far the web has come. I remember the first time I saw a browser GameBoy emulator and I was amazed. Maybe I should port my GB emulator to WASM...

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#29

Post by dimes »

Jnr wrote: post #16

Interesting that Firefox by default did not render the fizzbuzz demo correctly by default. I had to click the canvas icon next to address bar and allow the canvas usage. And it did not show a prompt either. It just looked broken by default. Screenshot from Firefox vs Chrome https://i.imgur.com/Af8nTim.png

You probably have resist fingerprinting turned on

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#30

Post by steveklabnik »

staticassertion wrote: post #23
Deukhoofd wrote: post #21

Earlier quoted context omitted.

Why would WASM have garbage collection? It's an assembly target, not a runtime. What if languages would want different memory management strategies? I know it's an existing proposal for WASM, but it feels so massively out of scope. If the issue is having to include runtimes in the WASM binary it might be more useful to think about how we could serve runtimes in a more efficient way.

I feel the same way. I find it very odd that GC is something that WASM ever intends to think about. If shipping your entire runtime sucks, find a smaller runtime?

Think of it more of "integration with a host environment's runtime" than a "adding a runtime to wasm directly."

(At least, that's what it used to be; I haven't been involved in WebAssembly for a long time.)

Post reply on HN