Slashdot Mirror

I was curious what WebAssembly was, so I hunted down an FAQ.

Summary is that WebAssembly is a binary format to use in place of Javascript, to avoid parsing time.

Really happy to see LLVM carry on, what a great project!

So what added value will AMD bring to a platform that's used mainly for casual web browsing? I doubt there are any compelling online games that will run on the Chromebook's notoriously small storage space? Ultra HD videos are out of the picture unless Google comes out with a tabloid size Chromebook (a Chromepaper?).

I'm using Web Assembly to build my C++ app for the web. It can use OpenGL, so it would benefit from being able to use the GPU for drawing. For a Windows equivalent: if you write some dot net app using XAML for the UI, it will render using DirectX to accelerate the drawing of vector based assets. It doesn't even have to be running the latest AAA microtransaction shitfest, or a 4K video, or my example app above, to benefit from having a GPU. Even regular 2D rendering of your web page will be using the GPU for drawing, here's some old stats

This states that WASM is not SSA, though it can be decoded to a compiler's internal SSA form.

While it's not exactly a competitor, the Mill architecture similarly provides an abstraction of the physical ISA that is more amenable to compilers. However, the Mill hardware itself is fundamentally SSA in nature, and naturally extends to a generalized form, presenting a genuine SSA target for compilers.

Just wait until WebAssembly is forced down our throats, like has been done with so many other shitty web technologies.

Your browser will be running obscure bytecode that takes more work and effort to analyze than even obfuscated JavaScript code does.

WebAssembly supporters will usually start blabbering on about "sandboxing" at this point, but if there's one thing we should have learned about sandboxing is that it's never perfect. There's always some way that it ends up leaking, or is exploited, or suffers from bugs.

Frankly, I find it kind of sad that the same kinds of people who were screaming bloody murder about things like Java applets and Flash are now the same kinds of people who are pushing hard for WebAssembly.

At least with Java applets and Flash we could easily avoid them by just not installing the plugins that implemented that functionality. But WebAssembly? It'll be built in to our browsers, and we won't be able to easily remove it. Even if it could perhaps be disabled, it will likely be impossible to remove all traces of its code from one's system.

Unwanted cryptocurrency mining is just one small threat that's amplified by this WebAssembly nonsense that's being crammed down our throats and up our asses.

which the end user won't be able to access anymore

No. You can view source on WebAssembly modules. Also see the FAQ.

Ya, but that's not the original language source from, say C, etc... just the Web Assembly text.

which the end user won't be able to access anymore

No. You can view source on WebAssembly modules. Also see the FAQ.

Ya, but that's not the original language source from, say C, etc... just the Web Assembly text.

... Web Assembly is just a more compact serialization (binary instead of text) of a subset of EcmaScript/JavaScript.....

Much of what you say is morally true. But it's not technically true.

It's true that wasm is a binary serialisation of an abstract syntax tree (AST) but that AST is defined _without reference to JavaScript_, see https://github.com/WebAssembly... . In contrast, the asm.js spec is genuinely a subset of JavaScript.

You're right that wasm doesn't introduce new capabilities to the browser as such. In the current 'MVP' version of wasm, the only way to invoke web assembly is via JavaScript, and the only way for wasm code to interact with the browser is via JavaScript.

But it does make certain scenarios, such as running large compiled C programs, much more practical. It is, by design, a far more efficient compilation target than JavaScript or asm.js, see https://github.com/WebAssembly... . For example, we can expect Unity running on wasm to become commonplace, see http://webassembly.org/demo/ .

...if there are security issues with WAsm, they're also present in plain JS,...

You can't be sure of that. The wasm codepaths will reuse much of the existing JavaScript execution engine but there will be new code and that new code could - and probably will - have security vulnerabilities. But probably no more than any other major browser feature.

we will no longer be able to monitor and audit the content of web pages and the scripts.

False. Read the FAQ.

which the end user won't be able to access anymore

No. You can view source on WebAssembly modules. Also see the FAQ.

which the end user won't be able to access anymore

No. You can view source on WebAssembly modules. Also see the FAQ.

That sounds like a frequently asked question.

This would appear to solve so much trouble caused by JS.

More info for those interested:
http://webassembly.org/docs/se...

Each WebAssembly module executes within a sandboxed environment separated from the host runtime using fault isolation techniques. This implies:

1. Applications execute independently, and canâ(TM)t escape the sandbox without going through appropriate APIs.
2. Applications generally execute deterministically with limited exceptions.

Aaaaaand:

The design of WebAssembly promotes safe programs by eliminating dangerous features from its execution semantics, while maintaining compatibility with programs written for C/C++.

Provided this is designed & implemented with an end-user-first mentality, sign me up! If it's designed with a Facebook-shareholders-first mentality, it will trigger another Noscript update to deny webassembly reqs from unknown hosts...etc.

tl;dr: just make the web work with the end users in mind not the greedy sods

Webassembly is supposed to replace javascript.

No, it's not. WebAssembly is meant to compliment JS by allowing you to write native extensions in a manner not dissimilar to how native Node.js modules work.

There does not appear to be any serious work being done to enable languages other than JS to access the DOM. It would be a lot of work and almost nobody has any interest in building whole webapp UIs natively bypassing the DOM for UI drawing.

So for the time being, the practical applications for wasm are limited mainly to niche high performance backend computations and using it to do native 2d/3d UI drawing for stuff like games.

Java is still used for serverside technologies.

And it's losing market share to JavaScript via Node.js.

This whole narrative that JS is about to be replaced by [x] or even needs to be replaced by anything at all to begin with is typical programmer tribalism. The truth is this: JS is under active development by the ECMA standardization process and is getting tons of new features and refinements all the time. What legitimate criticisms people make about the language are being addressed by this standardization process and with each passing year, those criticisms fade from relevance more and more. As time passes, and those legitimate criticisms are dealt with, it leaves only the rotten core of programmer tribalism left as the only reason to loathe this incredibly popular and successful language so much.

It's just a tool, people. Use it when it's the right tool for the job. Use something else when something else is the right tool for the job. Don't get upset that JavaScript is becoming the right tool for more jobs than it used to be. Things change.

The official WebAssembly FAQ throws shade at that attitude.

Is WebAssembly trying to replace JavaScript?

No!

It goes on to say that WebAssembly is meant to encourage hybrid stacks.

It's much more likely the end result will be an ecosystem similar to Node.js, where some stuff is in JS, and other stuff is in native node modules.

Maybe my english isn't good enough, but if "dynamic" means "dynamically typed" here, then the sentence as a whole doesn't mean too much. WebAssembly (wasm) is clearly a target for mostly statically typed, compiled languages. And future plans point to direct access to the page DOM and other Web APIs. If this becomes real, I will happily forget about JavaScript for ever..

The module definition http://webassembly.org/docs/mo... omits basic metadata such as author and version information and there is no defined place to sign the binary. I know they want small but I am sick and tired of browsers having to run unattributable code. Their security model looks like it ignores attacks such as an "enhanced" advertisement filtering all browser key strokes from a background thread and sending them home.

It's happening, and it's called WebAssembly.