AKA how to bring more advertising and tracking crap to your browser...I really do hope it's not that.
Bringing the web up to speed with WebAssembly
11–20 of 172 posts
Re: Bringing the web up to speed with WebAssembly
#12WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
> Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc).
I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
Re: Bringing the web up to speed with WebAssembly
#13WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, wh…
> For your second point, JavaScript is also sandboxed.
There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on....
To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO.
WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
Re: Bringing the web up to speed with WebAssembly
#14WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, wh…
You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.
Re: Bringing the web up to speed with WebAssembly
#15My worry is, does this make it easier for the big companies to silo the internet more completely? From a developer POV with regard to performance, this seems great, but from the standpoint of open communication, it seems problematic.
It doesn't make it any easier than minified, obfuscated JS.
Re: Bringing the web up to speed with WebAssembly
#16WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
> Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently. http://webassembly.org…
I did not see native DOM interaction in that document and the thing it linked to is 404.
Re: Bringing the web up to speed with WebAssembly
#17Earlier quoted context omitted.
> ..., to the web And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, wh…
> For your second point, JavaScript is also sandboxed. There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on.... To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity wh…
Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc.
See the design documents: https://github.com/WebAssembly/design/blob/master/Portabilit...
Re: Bringing the web up to speed with WebAssembly
#18WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems.
If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?
Re: Bringing the web up to speed with WebAssembly
#19Earlier quoted context omitted.
> Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently. http://webassembly.org…
I did not see native DOM interaction in that document and the thing it linked to is 404.
Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeat...
It now links to here: https://github.com/WebAssembly/design/issues/1079
The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
Re: Bringing the web up to speed with WebAssembly
#20We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?