3 ms·
It's not tiny in the sense of file size, it's tiny in the sense of scope. It doesn't even have a standard library, let alone offer everything flash and Java did
by hackcasual 8y ago
It's not tiny in the sense of file size, it's tiny in the sense of scope. It doesn't even have a standard library, let alone offer everything flash and Java did. At it's heart it's just a compact, efficient representation of a subset of JavaScript
- sitkack 8y ago> 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.md https://github.com/WebAssembly/design/blob/master/Semantics....
- steveklabnik 8y agoIt's so much not JavaScript that you cannot even compile JavaScript to wasm!
- int_19h 8y agoWait... why? What's the limiting factor?
- steveklabnik 8y agothere’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.
- int_19h 8y agoOh, 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.
- hackcasual 8y agoI'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.