WebAssembly First Public Working Drafts

Re:WebAssembly First Public Working Drafts by hackcasual on Thursday February 15, 2018 @07:33PM (#16389016)

The alternative is that it's a bloated piece of tech that ends up the way of Flash/Applets.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by thefounder on Friday February 16, 2018 @04:36AM (#16391089)

I believe flash and java applets were something else than WASM.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by hackcasual on Friday February 16, 2018 @11:59AM (#16393709)

Right, they were their own separate VMs, with a lot of duplicated functionality. WASM is just a way to get native, non memory managed languages executing efficiently in a JavaScript environment.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by username223 on Thursday February 15, 2018 @08:19PM (#16389211)

I.e. disabled and eventually removed? I could live with that.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by banhfun on Thursday February 15, 2018 @07:36PM (#16389029)

Now that makes me wonder what the point of WASM is because we could have always transpiled code to JS

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by themihai on Friday February 16, 2018 @05:10AM (#16391257)

Transpilation to JS always sucks. JS was not designed as a compiler target. The point of WASM is exactly that: Compile any language on the web without getting into the JS limitation.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by bastawhiz on Thursday February 15, 2018 @08:35PM (#16389277)

Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to machine code. Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by amaranth on Friday February 16, 2018 @09:16AM (#16392428)

Thanks to Spectre I don't think we'll be seeing threads anytime soon. Well, not threads with shared memory anyway which removes a lot of the point of them. Same reason JavaScript just lost SharedArrayBuffer, too easy to make a high precision timer out of it.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by kllrnohj on Thursday February 15, 2018 @09:11PM (#16389386)

> Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.

There's no reason JavaScript couldn't just have those features. It already has some amount of memory allocation control via ArrayBuffer & DataView.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by imtringued on Friday February 16, 2018 @06:34AM (#16391617)

You're describing asm.js which had significant issues as a compilation target. The generated javascript code was massive and it took several seconds just to parse it.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by caseymarquis on Friday February 16, 2018 @08:31AM (#16392161)

Related is a mozilla post on streaming wasm for big performance gains: https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by kllrnohj on Thursday February 22, 2018 @11:54AM (#16438987)

asm.js never added threads, which is a far bigger performance issue than fine-grained manual memory allocation is.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by malcolmwhite on Thursday February 15, 2018 @09:47PM (#16389504)

Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by Ono-Sendai on Thursday February 15, 2018 @08:39PM (#16389287)

Is that just the current state of affairs, or will it always be like that?

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by undecidabot on Thursday February 15, 2018 @09:38PM (#16389472)

Just for now, it seems. It's tied together with the GC support: https://github.com/WebAssembly/design/issues/1079. I wouldn't expect it anytime soon though.

[ Parent | on HN ]

Re:WebAssembly First Public Working Drafts by steveklabnik on Friday February 16, 2018 @10:04AM (#16392792)

It is not tied together with GC support; that used to be the case, but https://github.com/WebAssembly/host-bindings/ is the way forward.

[ Parent | on HN ]