The Start Of WebAssembly Support Lands In LLVM

[phoronix]

Phoronix: The Start Of WebAssembly Support Lands In LLVM

As mentioned in this week's LLVM Weekly, the initial WebAssembly back-end was committed to the mainline LLVM code-base but it is not yet functional...

http://www.phoronix.com/scan.php?pag...M-First-Commit

[Maxjen]

I think WebAssembly will eventually be the foundation of the VR metaverse, so it's good to hear that progress is being made. The only thing that makes me a bit sad is that there probably wont be a WebVulkan (according to this podcast at about minute 17). I hope that WebGL will still benefit as much as possible from the higher quality drivers that Vulkan will bring.

[asdfblah]

Heh, I read "The Art Of WebAssembly"...

[dstaubsauger]

Is nobody concerned that this is going to kill what we today know as the "open web"?

I mean, even obfuscated JS code is somewhat easy to reverse engineer, at least compared to any kind of machine language. If they implement this and it gains adoption (which it will, because form a technical/performance standpoint, WebAssembly is far superior to JS), every website you visit will execute obscure binary code. Maybe they may even bring their own rendering engines, etc.

It seems to me now that RMS was right when he complained about the "javascript trap", and obscure byte code is way worse than minified js.

[Lennie]

I think WebAssembly will eventually be the foundation of the VR metaverse, so it's good to hear that progress is being made. The only thing that makes me a bit sad is that there probably wont be a WebVulkan (according to this podcast at about minute 17). I hope that WebGL will still benefit as much as possible from the higher quality drivers that Vulkan will bring.

But a future standard probably ends up using Vulkan.

WebGL is currently based on an existing 'mobile OpenGL' spec (OpenGL ES). WebGL2 will do the same, a newer version of OpenGL ES.

WebGL2 and WebVR are currently being worked on, they'll use existing hardware capabilities.

Have we seen a large share of the hardware products that implement Vulkan yet ? Currently their stance is: then why make a webstandard ?

[Lennie]

Is nobody concerned that this is going to kill what we today know as the "open web"?

I mean, even obfuscated JS code is somewhat easy to reverse engineer, at least compared to any kind of machine language. If they implement this and it gains adoption (which it will, because form a technical/performance standpoint, WebAssembly is far superior to JS), every website you visit will execute obscure binary code. Maybe they may even bring their own rendering engines, etc.

It seems to me now that RMS was right when he complained about the "javascript trap", and obscure byte code is way worse than minified js.

Yes I am. I'm so concerned that any Javascript code I create is covered by the L-GPL.

It will do multiple things, the positive things:
- allow more webdevelopers to squeeze out the last bit of performance they need (even if it's just part of their webapp)
- it will allow webdevelopers to use more existing non-Javascript code.
- more native developers will get to know the web stack

I'm hoping for a net-positive.

[Maxjen]

But a future standard probably ends up using Vulkan.

I think a problem with Vulkan for the Web might be that it gives developers too much low level control to be properly sandboxed. But maybe they will build something higher level that uses Vulkan internally.

Is nobody concerned that this is going to kill what we today know as the "open web"?

I mean, even obfuscated JS code is somewhat easy to reverse engineer, at least compared to any kind of machine language.

According to the FAQ it will still be possible to view the source in a somewhat readable text format.

Will WebAssembly support View Source on the Web?

Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.

[smitty3268]

Is nobody concerned that this is going to kill what we today know as the "open web"?

Yes, I am.

and obscure byte code is way worse than minified js.

Except that's where you lose me. It's going to be trivial to reverse this back to something very similar to minified js code. That's their whole plan covering backwards compatibility in older browsers, in fact.

So it's really the same thing we have now, just taken 1 logical step further. If it becomes commonplace for every script to be done this way, that's not going to be great. But if it's just the ones that are already being minified I don't see it making much of a difference.

[Greijoan]

I mean, even obfuscated JS code is somewhat easy to reverse engineer, at least compared to any kind of machine language. If they implement this and it gains adoption [...], every website you visit will execute obscure binary code.

I don't think it will change things. Java is binary since day 1, and it's not a problem to decompile the binary code to *readable* source code (in fact, this is so common that this functionality is built-in in some Java IDEs). Same thing with Python, Erlang. A person analysing a minified/obfuscated JavaScript needs to use a beautifier-like tool to be able to read JS, and with WebAssembly this beautifier tool will be switched to a decompiler. That's all.