Live data from Hacker News

WebAssembly from Scratch: From FizzBuzz to DooM

github.com

11–20 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#11
post #4

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.

That was the original message used to sell WebAssembly, however when the real goal is to replace ActiveX, Flash, Silverlight and PNaCL it was obvious that it would grew beyond that.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#13

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.

The difficulty is inherent; C, C++ and so on live in a very different world to JavaScript. Whether or not WebAssembly had direct interaction with JavaScript objects at launch or not, writing bridging code would still be tedious.

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

#14
post #3

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.

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

thank you

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#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

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#17

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

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#18
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

FF 89 worked fine here (mac), either your FF version is old or it's some sort of FF/linux issue ?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#19
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 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.

Post reply on HN