Universal Binaries Using WASM

Re:Universal Binaries Using WASM by sitkack on Tuesday February 26, 2019 @05:30PM (#19258950)

> At it's heart it's just a compact, efficient representation of a subset of JavaScript

WASM is a well specified encoding for a stack based machine with the following 4 types, i32, i64, f32 and f64. It is very much not JavaScript.

https://github.com/WebAssembly/design/blob/master/Semantics....

[ Parent | on HN ]

Re:Universal Binaries Using WASM by hackcasual on Thursday February 28, 2019 @03:31PM (#19274873)

I'm speaking of asm.js. Other than i64, all of those types can be operated on in JavaScript. WASM is just a better representation of that.

WASM was intentionally designed to be able to integrate easily with existing JS implementations.

[ Parent | on HN ]

Re:Universal Binaries Using WASM by steveklabnik on Tuesday February 26, 2019 @06:04PM (#19259243)

It's so much not JavaScript that you cannot even compile JavaScript to wasm!

[ Parent | on HN ]

Re:Universal Binaries Using WASM by int_19h on Tuesday February 26, 2019 @07:05PM (#19259663)

Wait... why? What's the limiting factor?

[ Parent | on HN ]

Re:Universal Binaries Using WASM by steveklabnik on Tuesday February 26, 2019 @10:55PM (#19260737)

there’s not a lot of reason to. In the browser, you already have a JS environment. It’s easier to add a wasm environment to it than it is to re-write the world. Additionally, wasm doesn’t have a GC, and is not really optimized for dynamic languages, so there’s just not a lot of reason to do it.

[ Parent | on HN ]

Re:Universal Binaries Using WASM by int_19h on Wednesday February 27, 2019 @03:23AM (#19261798)

Oh, I thought you mean that there's some fundamental reason why it can't be done. Ofc it's pointless today, but I wouldn't be surprised if JS in browsers eventually becomes a layer on top of wasm.

[ Parent | on HN ]