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

71–80 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#71

Post by cubano »

franz899 wrote: post #4
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.

WebAssembly's purpose was never to replace JavaScript but only to speed up certain parts of a website/app.

really? i thought it's purpose was to take us back to the good old days of sellable proprietary binary blobs instead of the more open HTML/JS/CSS stack.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#72

Post by Dylan16807 »

plopz wrote: post #61
asiachick wrote: post #40

Earlier quoted context omitted.

You could pass it via a SharedArrayBuffer

From what I found on MDN "a side effect to the block in one agent will eventually become visible in the other agent", what does the word eventually mean there, what's going on under the hood?

Should just be nanoseconds. I think they're mostly making considerations for unfortunate thread scheduling where one gets stuck for a while.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#73

Post by jollybean »

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.

WASM is supposed to be 'assembly' level a little bit like java bytecodes. So it's lower level than 'strings'.

But as you have pointed out, the missing layer on top i.e. the 'thing we can practically use' is a big gaping hole and it's a little bit diabolical.

The fact that JS has gotten so much faster and the lack of both higher-level abstractions and notably a really good 'bridge' to JS means it's lagged in terms of material applicability.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#75

Post by anthk »

paulgb wrote: post #64
sigg3 wrote: post #48

Earlier quoted context omitted.

> It's incredible how far the web has come. I agree and disagree. It seems like no one is questioning why we need to use legacy web browsers in between all the code we're executing locally. It's like a new iteration of old tech like lisp machines, which started out as specific purpose only to grow into complete environments (afaik). In this regard, we haven't come far, it's just the syntax that has changed.

For one thing, I’m unlikely to download a native copy of Doom to run on my own machine from a strange website. The ability to run cross-platform code that uses my GPU in a secure sandbox is pretty neat to me.

prboom-plus is open source, FFS.

Also, you have FreeDoom.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#76

Post by westoncb »

throw_m239339 wrote: post #35
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…

Seems to me the original rendering pipeline wasn't GPU based. The author is just dumping whatever the game renders in a canvas element, there is no need for webgl for that. Also Canvas is getting some GPU acceleration in some browsers: https://developers.google.com/web/updates/2012/07/Taking-adv...

GP was asking whether it would be more performant to do via webgl though. (It's already known that canvas is currently used)

My bet is that webgl probably would be, but I'd also be curious to hear from someone with more info.

Seems to basically come down to whether canvas of webgl does a more efficient version of some kind of memory copy onto the GPU side.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#77

Post by 1vuio0pswjnm7 »

Quekid5 wrote: post #65
milliams wrote: post #5

I found this video https://www.youtube.com/watch?v=r-A78RgMhZU "A Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter)" to be a brilliant introduction to WASM as well as writing interpreters in general. I'm a relative novice in the subject and it was pitched right at my level.

Dave Beazley is a truly amazing presenter. Another favorite of his of mine is his epic tale of how he ended up demolishing an opposing side's case in a civil lawsuit... by sheer luck of having a Python interpreter avaialable. For for you viewing pleasure: https://www.youtube.com/watch?v=RZ4Sn-Y7AP8

I learned about this author from SWIG. I have always liked that project. https://en.wikipedia.org/wiki/SWIG

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#78

Post by ronsor »

Mizza wrote: post #42

I love seeing this kind of tutorial, that isn't just a step-by-step guide, but also an exploration of the thought process and trial-and-error that goes on in crafting each step, so thanks for sharing. Looks like a lot of the work on the Doom port ( https://github.com/diekmann/wasm-fizzbuzz/tree/main/doom ) is about getting common functions from the C standard library to work in WASM. Surely this seems like a good opp…

There's already wasi-libc: https://github.com/WebAssembly/wasi-libc

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#79

Post by miohtama »

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…

DOM manipulation is slow is pretty much busted misconception today:

https://svelte.dev/blog/virtual-dom-is-pure-overhead

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#80

Post by pjmlp »

titzer wrote: post #68
pjmlp wrote: post #37

Earlier quoted context omitted.

The problem is that each runtime has different GC requirements, so at best it will mean WASM GC semantics will be the underlying JS GC semantics, probably not what you want for a D or .NET GC, for example.

No one has ever articulated the details of what they mean by these runtimes having different GC requirements. JavaScript garbage collection has no "semantics"--it is entirely invisible to applications. Even WeakMap and WeakSet do not expose garbage collection details because they are not iterable. The memory profile of JavaScript applications tends to look a lot like the memory profile of typical Java applications. I…

For example, the existing JS GC doesn't need to expose ability to stop the GC, execute on demand, support value types, pinning memory, interior pointers, control GC regions, marshaling to native code to the developer, whereas a .NET or D GC does.

So if a future WASM GC doesn't offer APIs for such capabilities, it is useless from those runtimes point of view.

Post reply on HN