WebAssembly from Scratch: From FizzBuzz to DooM
1–10 of 95 posts
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#2I 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.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#3I 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.
Afaik for the WebAssembly MVP, the goal was to have a simple, efficient compile target - therefore only integers and floats. To make wasm more useful & easier to integrate, the plan calls for interface types[0], which allow both accessing complex (JS) objects and calling browser APIs.
[0] https://github.com/WebAssembly/interface-types/blob/master/p...
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#4I 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.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#5I 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.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#6I 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.
that's not how I remember it:
https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
edit: from the linked article, in case it isn't clear, an HN comment by eich:
"Sure, in userland many languages compile to assembly. Hmm, where have I heard that word lately?"[1]
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#7I 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.
The lack of strings makes sense, as many different languages and standard libraries have their own implementations of it, that can behave slightly differently. It now puts the implementation of the string to the compilers/linkers, as is generally the case for assembly as well.
The lack of a DOM API is something I sorely miss as well. It's currently possible (and not that hard, you can just interact with JS), but comes with such performance overhead that you lose the entire benefit of WASM.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#8I 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.
Afaik for the WebAssembly MVP, the goal was to have a simple, efficient compile target - therefore only integers and floats. To make wasm more useful & easier to integrate, the plan calls for interface types[0], which allow both accessing complex (JS) objects and calling browser APIs. [0] https://github.com/WebAssembly/interface-types/blob/master/p...
interesting, thank you
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#9If you'd like to try (multiplayer) Doom in WASM there's https://silentspacemarine.com/
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#10I 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 Javascript uses.
The Emscripten SDK offers helper functions to marshal high level data types like Javascript strings to UTF-8 encoded C strings on the WASM heap and back to JS, so it's not that bad.
DOM access can be achieved with helper libraries which call out into JS. And since any sort of DOM manipulation is extremely slow anyway there's not much of a performance difference even with the overhead of calling out from WASM into JS (which actually is quite fast nowadays).