Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

1–10 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#5
It's simple.

JavaScript is the right abstraction for running untrusted apps in a browser.

WebAssembly is the wrong abstraction for running untrusted apps in a browser.

Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.

Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented.

WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web.

Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it.

I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.

Re: Making WebAssembly a first-class language on the Web

#6
It's still not a great idea IMHO ;)

(there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837)

E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM.

E.g. if I mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).

It would be nice to see some benchmarks for WebGL2 and WebGPU with tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.

Re: Making WebAssembly a first-class language on the Web

#7

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in…

That's just like your opinion man ;)

(I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)

Re: Making WebAssembly a first-class language on the Web

#8

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in…

That's just like your opinion man ;) (I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)

Then give me a counterargument instead of just saying that I'm wrong.

My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.

Re: Making WebAssembly a first-class language on the Web

#9
This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time.)

Better late than never I guess.

[1] https://github.com/WebAssembly/interface-types/commit/f8ba0d...

[2] https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...

[3] https://queue.acm.org/detail.cfm?id=3746174

Re: Making WebAssembly a first-class language on the Web

#10

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in…

I'm not sure I follow this.

> WebAssembly is the wrong abstraction for running untrusted apps in a browser

WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.

> Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.

There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.

> Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented

The first major language for WebAssembly was C++, which is object oriented.

To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.

Post reply on HN