> 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?
Not sure yet. :) Some languages that are interesting include Swift, Rust, and OCaml, but we'll see where things go and how they work with WebAssembly.
I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......
As someone who works in VR this is something I've been thinking about a lot. We need an open platform for creating and sharing VR content which is 3D rendered. WebAssembly + WebVR + WebGL might be the beginning of that platform.
Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear. I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.
Things are definitely picking up speed! There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines. We've still got a long ways to go, but it's much nearer than 10+ years! [0]: https://github.com/WebAssembly/wasm-jit-prototype [1]: https…
Very good news! It is exciting. I am looking forward to this.
I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......
This would be terrible for the web from crawl-ability, accessibility, extension and OS integration points of view. The web is awesome because it's document based, and largely because of links embedded in a open document format. Get rid of the document and you get rid of readable links, web crawlers, find-in-page, screen readers, and on and on...
This assumes what you want is documents. The web is already great for documents. Meanwhile, a lot of people also want apps. You can bemoan document viewers being stretched beyond reason into app platforms, but it already happened over a decade ago and shows no sign of slowing. It's time to just deal with it. With wasm and webgl, these document viewers can at least be slightly less crappy app platforms.
It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.
It's possible to eschew the DOM even today with just JavaScript & [0]! While this would be possible with wasm & WebGL as well, we're working to build something that integrates well into the open web platform. Check out #3 from our high-level goals [1]. [0]: https://github.com/Flipboard/react-canvas [1]: https://github.com/WebAssembly/design/blob/master/HighLevelG...
Doesn't flipboard still use the DOM to do the initial rasterization? I thought it just used canvas as a caching layer.
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…
WebAssembly is just a new storage format for asm.js, which is just a javascript subset. It doesn't replace the DOM. That still exists just as it does with Javascript! Any openness problems that exist with WebAssembly already exist with minified Javascript.
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…
That's not really the use case for it, the use case for Web Assembly is to take web audio and turn it from being a kind of toy into a platform where an ableton live could be empowered to run in the browser, as well as being able to load native plugins for audio processing and generation. Also say you want to transcode a video file from webm to hls, with web assembly that becomes possible, even with asm.js its really brutally slow to try to do that.
I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......
It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.
Flash and Java applets were (and are) kind of terrible, but the basic premise of compiled binary applications accessible as embeds in a browser is, I think, potentially more revolutionary than even that of the web as linked documents. It just may be that the first iteration of this was too primitive to realize its true potential, and the traditional javascript run "web app" is just an awkward interstitial phase we have to get past.
Although... I also think that at some point the line between the web, browser and operating system might have to blur or disappear entirely.
You'll be able to reverse engineer. Interpreting JS is a massive waste of CPU/battery for the majority of users. The savings is worth a slight increase in complexity for developers.
The solution to high CPU/battery usage is to send a static page . Invoking a new type of VM may help slightly , but it probably just moves the problem around.
A static page ? What about games? Are you advocating to go back to Adobe Flash?
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…
> and I fear it will introduce the Halting Problem in to a lot more areas.
This is the part of your post where I concluded that you were deeply confused and stopped reading. The didactic part of me wants to teach you what the halting problem is, but I'm not even sure what it is you don't know at this point.