Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Assembly

github.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Web Assembly

#31

Post by andrewchambers »

pdkl95 wrote: post #22
s3th wrote: post #10

Earlier quoted context omitted.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

All this is already done with asm.js and emscripten.

Re: Web Assembly

#32

Post by reissbaker »

pdkl95 wrote: post #22
s3th wrote: post #10

Earlier quoted context omitted.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

This is uneducated FUD.

WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is.

If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed.

And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.

Re: Web Assembly

#33

Post by Nrpf »

s3th wrote: post #21
spicyj wrote: post #18

Earlier quoted context omitted.

> As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly. Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.

We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform. [0]: https://github.com/WebAssembly/design/blob/master/GC.md

Any chance python could be a first class citizen here, or are we looking at more compile-able languages?

Re: Web Assembly

#35

Post by cwyers »

pdkl95 wrote: post #22
s3th wrote: post #10

Earlier quoted context omitted.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

> The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM.

Um, the DOM will still exist.

Re: Web Assembly

#36

Post by s3th »

Nrpf wrote: post #33
s3th wrote: post #21

Earlier quoted context omitted.

We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform. [0]: https://github.com/WebAssembly/design/blob/master/GC.md

Any chance python could be a first class citizen here, or are we looking at more compile-able languages?

Check out the last paragraph of "Is WebAssembly only for C/C++ Programmers?" in the FAQ [0]. The tl;dr is that you'll be able to port a Python interpreter (that is itself written in C) to WebAssembly from day 1, but a more robust solution that relies on WebAssembly GC will have to wait until after the MVP.

[0]: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

Re: Web Assembly

#37

Post by userbinator »

reissbaker wrote: post #32
pdkl95 wrote: post #22

Earlier quoted context omitted.

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to r…

Just block the network requests and you're done.

Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods.

That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.

Re: Web Assembly

#38

Post by cpeterso »

richdougherty wrote: post #8
cauterize wrote: post #4

As someone who works in the web space, albeit on the back-end, can anyone explain why a project like this is desired over a better language / run-time?

wasm and asm.js are perfect examples of incremental improvements rather than building something from scratch. The benefit of this is that incremental improvements can be built slowly on top of existing deployed JavaScript engines, whereas writing something from scratch has a serious bootstrapping problem. The wasm/asm.js story goes like this so far: 1. emscripten, a JavaScript backend for LLVM, demonstrates that you…

How long until someone implements WebAssembly instructions in hardware? ARM's "Jazelle" supported some JVM instructions in hardware.

Re: Web Assembly

#39

Post by cpeterso »

spicyj wrote: post #18
s3th wrote: post #11

Earlier quoted context omitted.

We're working hard to make sure that WebAssembly is a first-class citizen in the open web platform in ways that other native execution environments didn't accomplish. For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that…

> As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly. Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.

What are some use cases for WebAssembly in React? What source language might React use to generate the WebAssembly code?

Re: Web Assembly

#40

Post by tsenior »

reissbaker wrote: post #32
pdkl95 wrote: post #22

Earlier quoted context omitted.

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to r…

Maybe they were referring to embedding the advertisers code into the code base itself without network calls? But I still don't see how this is any different than current sites that serve ad content through their own servers.
Post reply on HN