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.
WebAssembly from Scratch: From FizzBuzz to DooM
11–20 of 95 posts
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#12Re: WebAssembly from Scratch: From FizzBuzz to DooM
#13I 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.
But there's no reason you must write this yourself. Others have done the hard work for you and written libraries.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#14I 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
#15Re: WebAssembly from Scratch: From FizzBuzz to DooM
#16Screenshot from Firefox vs Chrome https://i.imgur.com/Af8nTim.png
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#17I 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
#18Interesting 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
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#19Interesting 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
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 that's just harvesting data, not actually needed to function.
And yes, malicious sites can of course display themselves as falsely broken until you grant the permissions. But this makes them more annoying to use, granting a UX edge to the honest sites which don't request unnecessary permissions. In other words, the incentives of sites and users are more aligned.