Linked by Thom Holwerda on Thu 18th Jun 2015 16:15 UTC
General Development

But the people calling for a bytecode for the browser never went away, and they were never entirely wrong about the perceived advantages. And now they're going to get their wish. WebAssembly is a new project being worked on by people from Mozilla, Microsoft, Google, and Apple, to produce a bytecode for the Web.

WebAssembly, or wasm for short, is intended to be a portable bytecode that will be efficient for browsers to download and load, providing a more efficient target for compilers than plain JavaScript or even asm.js. Like, for example, .NET bytecode, wasm instructions operate on native machine types such as 32-bit integers, enabling efficient compilation. It's also designed to be extensible, to make it easy to add, say, support for SIMD instruction sets like SSE and AVX.

Order by: Score:
OMG
by franzrogar on Thu 18th Jun 2015 16:32 UTC
franzrogar
Member since:
2012-05-17

Please, raise your hands those who think that blobs inside the web is the latest of the WORST IDEAS from a security POV.

Reply Score: 6

RE: OMG
by WorknMan on Thu 18th Jun 2015 17:15 UTC in reply to "OMG"
WorknMan Member since:
2005-11-13

Please, raise your hands those who think that blobs inside the web is the latest of the WORST IDEAS from a security POV.


Right here ;) These things are TERRIBLE at security as it is.

Reply Score: 3

RE: OMG
by jpkx1984 on Thu 18th Jun 2015 17:25 UTC in reply to "OMG"
jpkx1984 Member since:
2015-01-06

Why is it bad for security? It is all sandboxed. Such bytecode is not less secure than Javascript.

Edited 2015-06-18 17:28 UTC

Reply Score: 6

RE[2]: OMG
by ddc_ on Thu 18th Jun 2015 19:48 UTC in reply to "RE: OMG"
ddc_ Member since:
2006-12-05

Such bytecode is not less secure than Javascript.

Exactly, such bytecode is dangerously insecure, just as Javascript is.

Reply Score: 4

RE[3]: OMG
by cfgr on Fri 19th Jun 2015 09:10 UTC in reply to "RE[2]: OMG"
cfgr Member since:
2009-07-18

Javascript itself is just a language, just like bytecode is basically a "language" (just a very simple one). It's the implementation of the interpreter that's potentially insecure.

One can argue that having this sort of flexibility for webpages causes a lot of security risks. But that's an entirely different argument than "bytecode is worse than what we have now (Javascript)", which is simply untrue, as Alfman nicely illustrated with the Javascript minimization process versus Java decompilers.

Reply Score: 3

RE[2]: OMG
by DeepThought on Fri 19th Jun 2015 17:27 UTC in reply to "RE: OMG"
DeepThought Member since:
2010-07-17

Why is it bad for security? It is all sandboxed. Such bytecode is not less secure than Javascript.


Sooner or later, the web programmer cry for more performance and the sandboxes get direct access for this and that. Starting with the right to access local files.

But with byte code, it will be harder to analyze what is going on.

Reply Score: 2

RE[3]: OMG
by Alfman on Fri 19th Jun 2015 21:18 UTC in reply to "RE[2]: OMG"
Alfman Member since:
2011-01-28

DeepThought,

Sooner or later, the web programmer cry for more performance and the sandboxes get direct access for this and that. Starting with the right to access local files.


Not really though. Security does not imply bad performance and high performance does not imply bad security. While specific implementations may have such problems, they are implementation weaknesses rather than intrinsic limitations.


VM based languages such as .net are executed as *native* applications. Yet the semantics of the language will keep it isolated. It cannot access anything outside of the VM unless native APIs are exposed to the VM. Therefor the VM has as much or as little access as we give it.

Another approach is to use memory manager unit based isolation. A *native* application running in it's own address space can't access anything outside of that space. It needs the operating system to expose an API to allow processes to escape the confines of their address space.

A script interpreter is not native because instructions are executed by a software state machine, making it dramatically slower. However this is not inherently more secure. Just as with the native approaches above, the state machine can have as much or as little access to outside of itself as the APIs expose to the interpreted language.


A language like javascript can be implemented using any of (or even a combination of) the above approaches and have the same level of security. Granted the implementations would be dramatically different, but having native code doesn't rule out high performance approaches.


But with byte code, it will be harder to analyze what is going on.


My posts earlier refute this very point; Javascript does not imply transparency. and although I haven't covered this as much, having a bytecode does not imply an opaque black box.

Edited 2015-06-19 21:32 UTC

Reply Score: 2

RE: OMG
by Alfman on Thu 18th Jun 2015 18:01 UTC in reply to "OMG"
Alfman Member since:
2011-01-28

franzrogar,

Please, raise your hands those who think that blobs inside the web is the latest of the WORST IDEAS from a security POV.


Because this is so much better...

var SQL = (function () {
function e(a){throw a;}var g=void 0,k=!0,l=null,m=!1;function n(){return function(){}}var q,r;r||(r=eval("(function() { try { return Module || {} } catch(e) { return {} } })()"));var aa={},ba;for(ba in r)r.hasOwnProperty(ba)&&(aa[ba]=r[ba]);var s="object"===typeof process&&"function"===typeof require,da="object"===typeof window,ea="function"===typeof importScripts,ga=!da&&!s&&!ea;
if(s){r.print||(r.print=function(a){process.stdout.write(a+"\n")});r.printErr||(r.printErr=function(a){process.stderr.write(a+"\n")});var ha=require("fs"),ia=require("path");r.read=function(a,b){var a=ia.normalize(a),c=ha.readFileSync(a);!c&&a!=ia.resolve(a)&&(a=path.j oin(__dirname,"..","src",a),c=ha.readFileSync(a));c&&!b&&(c=c.toSt ring());return c};r.readBinary=function(a){return r.read(a,k)};r.load=function(a){ja(read(a))};r.thisProgram=1<proces s.argv.length?process.argv[1].replace(/\\/g,"/"):
"unknown-program";r.arguments=process.argv.slice(2);"undefined"!== typeof module&&(module.exports=r);process.on("uncaughtException",function(a ){a instanceof ka||e(a)})}else ga?(r.print||(r.print=print),"undefined"!=typeof printErr&&(r.printErr=printErr),r.read="undefined"!=typeof read?read:function(){e("no read() available (jsc?)")},r.readBinary=function(a){if("function"===typeof readbuffer)return new Uint8Array(readbuffer(a));a=read(a,"binary");u("object"===typeof a);return a},"undefined"!=typeof scriptArgs?
r.arguments=scriptArgs:"undefined"!=typeof arguments&&(r.arguments=arguments),this.Module=r,eval("if (typeof gc === 'function' && gc.toString().indexOf('[native code]') > 0) var gc = undefined")):da||ea?(r.read=function(a){var b=new XMLHttpRequest;b.open("GET",a,m);b.send(l);return b.responseText},"undefined"!=typeof arguments&&(r.arguments=arguments),"undefined"!==typeof console?(r.print||(r.print=function(a){console.log(a)}),r.printErr||(r.printErr=function(a){console.log(a)})):r.print||(r.print=
n()),da?window.Module=r:r.load=importScripts):e("Unknown runtime environment. Where are we?");function ja(a){eval.call(l,a)}!r.load&&r.read&&(r.load=function(a){ja(r.read(a) )});r.print||(r.print=n());r.printErr||(r.printErr=r.print);r.arguments||(r.arguments=[]);r.thisProgram||(r.thisProgram="./this.program");r.print=r.print;r.Ca=r.printErr;r .preRun=[];r.postRun=[];for(ba in aa)aa.hasOwnProperty(ba)&&(r[ba]=aa[ba]);
var w={Lf:function(a){la=a},Ye:function(){return la},Xb:function(){return v},Wb:function(a){v=a},qd:function(a){switch(a){case "i1":case "i8":return 1;case "i16":return 2;case "i32":return 4;case "i64":return 8;case "float":return 4;case "double":return 8;default:return"*"===a[a.length-1]?w.wa:"i"===a[0]?(a=parseInt(a. substr(1)),u(0===a%8),a/8):0}},Ve:function(a){return Math.max(w.qd(a),w.wa)},ei:16,zi:function(a,b,c){return!c&&("i64"==a ||"double"==a)?8:!a?Math.min(b,8):Math.min(b||(a?w.Ve(a):0),




The "human readable" quality of javascript became irrelevant when javascript became a compilation/obfuscation target. Alas, once we concede that reverse engineering is necessary to understand the code, then it's not really worse than a bytecode.

Another thing to consider is that some bytecodes, such as Java's, are so strongly structured that it's quite strait forward to produce very human readable source from them. In fact, if it weren't for the lack of comments, one might even mistake the decompiled code for the original source.

http://jd.benow.ca/

Conceivably, a browser's web developer tools might feature a WebAssembly reverse compiler. Not only would this render the bytecode transparent, but it could be much more readable than a lot of the obfuscated javascript or asm.js gibberish we have today.

Reply Score: 9

RE[2]: OMG
by shmerl on Thu 18th Jun 2015 21:13 UTC in reply to "RE: OMG"
shmerl Member since:
2010-06-08

It's done for compactness (I never understood why it couldn't be just compressed proper) to reduce load times. But you can easily restructure it back into normal format and it will still be way higher level code than WebAssembly.

Reply Score: 0

RE[3]: OMG
by Alfman on Thu 18th Jun 2015 21:45 UTC in reply to "RE[2]: OMG"
Alfman Member since:
2011-01-28

shmerl,

It's done for various reasons. But I want to make sure the point doesn't get lost that once you take this approach, it nullifies any benefit that javascript had in terms of readability.

Reply Score: 2

RE[2]: OMG
by galvanash on Thu 18th Jun 2015 21:58 UTC in reply to "RE: OMG"
galvanash Member since:
2006-01-25

Conceivably, a browser's web developer tools might feature a WebAssembly reverse compiler.


The initial design documents already mention that an isomorphic text format is mandatory for the MVP (i.e. minimally viable product). In other words version 1 will have a human readable text format that is equivalent to the binary format, and conversion between the two is lossless.

And of course you could always generate source maps to allow debugging using the original language semantics.

https://github.com/WebAssembly/design/blob/master/TextFormat.md

Reply Score: 2

RE[2]: OMG
by Lennie on Fri 19th Jun 2015 00:11 UTC in reply to "RE: OMG"
Lennie Member since:
2007-09-22

Really where is the problem ? I have no problem reading that code when I put it into this:

http://jsbeautifier.org/

It's even built-in to your browser:

https://developer.mozilla.org/nl/docs/Tools/Debugger#Pretty-print_a_...

There is no maybe, WebAssembly will support a text-format:

https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webass...

Edited 2015-06-19 00:13 UTC

Reply Score: 2

RE[3]: OMG
by Alfman on Fri 19th Jun 2015 01:59 UTC in reply to "RE[2]: OMG"
Alfman Member since:
2011-01-28

Lennie,

Really where is the problem ? I have no problem reading that code when I put it into this:


I neglected to say where this came from, but it was just a tiny fraction of a much larger piece of asm.js:

https://raw.githubusercontent.com/kripken/sql.js/master/js/sql.js

Take the code above and stuff it into the JS-beautifier:
http://jsbeautifier.org/

Do you get nicely formatted javascript? Sure, 100K lines of it. But is it any more understandable? Judge for yourself...

function pz(b, d, e) {
___b = b | 0;
___d = d | 0;
___e = e | 0;
___var f = 0,
______g = 0,
______h = 0,
______j = 0,
______k = 0,
______l = 0,
______m = 0,
______n = 0;
___l = i;
___i = i + 32 | 0;
___g = l + 28 | 0;
___k = l + 24 | 0;
___j = l + 20 | 0;
___n = l + 16 | 0;
___h = l + 12 | 0;
___f = l;
___m = l + 8 | 0;
___c[k >> 2] = b;
___c[j >> 2] = d;
___c[n >> 2] = e;
___e = c[n >> 2] | 0;
___if (!((c[n >> 2] | 0) >>> 0 <= 7 & (c[n >> 2] | 0) >>> 0 > 0))
______if (e >>> 0 >= 12) {
_________c[h >> 2] = c[(c[j >> 2] | 0) + 12 >> 2];
_________dF(c[k >> 2] | 0, c[(c[j >> 2] | 0) + 16 >> 2] | 0, c[h >> 2] | 0) | 0;
_________c[g >> 2] = c[h >> 2];
_________b = c[g >> 2] | 0;
_________i = l;
_________return b | 0
______} else {
_________c[g >> 2] = 0;
_________b = c[g >> 2] | 0;
_________i = l;
_________return b | 0
______}
___if ((e | 0) == 7) {
______b = c[j >> 2] | 0;
______c[f + 0 >> 2] = c[b + 0 >> 2];
______c[f + 4 >> 2] = c[b + 4 >> 2]
___} else {
______e = c[j >> 2] | 0;
______d = c[e + 4 >> 2] | 0;
______b = f;
______c[b >> 2] = c[e >> 2];
______c[b + 4 >> 2] = d
___}
___b = Ww(c[n >> 2] | 0) | 0;
___c[m >> 2] = b;
___c[h >> 2] = b;
___do {
______b = c[f >> 2] & 255;
______d = (c[m >> 2] | 0) + -1 | 0;
______c[m >> 2] = d;
______a[(c[k >> 2] | 0) + d >> 0] = b;
______d = f;
______d = cF(c[d >> 2] | 0, c[d + 4 >> 2] | 0, 8) | 0;
______b = f;
______c[b >> 2] = d;
______c[b + 4 >> 2] = D
___} while ((c[m >> 2] | 0) != 0);
___c[g >> 2] = c[h >> 2];
___b = c[g >> 2] | 0;
___i = l;
___return b | 0
}

function qz(f, g) {
___f = f | 0;
___g = g | 0;
___var h = 0,
______j = 0,
______k = 0,
______l = 0,
______m = 0,
______n = 0,
______o = 0,
______p = 0;
___l = i;
___i = i + 32 | 0;
___h = l + 28 | 0;
___o = l + 24 | 0;
___j = l + 20 | 0;
___k = l;
___m = l + 16 | 0;
___n = l + 12 | 0;
___p = l + 8 | 0;
___c[o >> 2] = f;
___c[j >> 2] = g;
___f = k;
___c[f >> 2] = 0;
___c[f + 4 >> 2] = 0;
___if (!(c[(c[o >> 2] | 0) + 60 >> 2] | 0)) {
______f = c[j >> 2] | 0;
______c[f >> 2] = 0;
______c[f + 4 >> 2] = 0;
______c[h >> 2] = 0;
______f = c[h >> 2] | 0;
______i = l;
______return f | 0
___}
___c[m >> 2] = Iw(c[o >> 2] | 0) | 0;
___a: while (1) {
______if (c[m >> 2] | 0) {
_________n = 16;
_________break
______}
______c[p >> 2] = c[(c[o >> 2] | 0) + 120 + (b[(c[o >> 2] | 0) + 76 >> 1] << 2) >> 2];
______if (!((d[(c[p >> 2] | 0) + 5 >> 0] | 0) == 0 ? (a[(c[p >> 2] | 0) + 2 >> 0] | 0) != 0 : 0)) {
_________g = k;
_________g = bF(c[g >> 2] | 0, c[g + 4 >> 2] | 0, e[(c[p >> 2] | 0) + 18 >> 1] | 0, 0) | 0;
_________f = k;
_________c[f >> 2] = g;
_________c[f + 4 >> 2] = D
______}
______if (a[(c[p >> 2] | 0) + 5 >> 0] | 0) {
_________do {
____________if (!(b[(c[o >> 2] | 0) + 76 >> 1] | 0)) {
_______________n = 10;
_______________break a
____________}
____________yw(c[o >> 2] | 0)
_________} while ((e[(c[o >> 2] | 0) + 78 + (b[(c[o >> 2] | 0) + 76 >> 1] << 1) >> 1] | 0) >= (e[(c[(c[o >> 2] | 0) + 120 + (b[(c[o >> 2] | 0) + 76 >> 1] << 2) >> 2] | 0) + 18 >> 1] | 0));
_________f = (c[o >> 2] | 0) + 78 + (b[(c[o >> 2] | 0) + 76 >> 1] << 1) | 0;
_________b[f >> 1] = (b[f >> 1] | 0) + 1 << 16 >> 16;
_________c[p >> 2] = c[(c[o >> 2] | 0) + 120 + (b[(c[o >> 2] | 0) + 76 >> 1] << 2) >> 2]
______}
______c[n >> 2] = e[(c[o >> 2] | 0) + 78 + (b[(c[o >> 2] | 0) + 76 >> 1] << 1) >> 1];
______f = c[o >> 2] | 0;
______g = c[p >> 2] | 0;
______if ((c[n >> 2] | 0) == (e[(c[p >> 2] | 0) + 18 >> 1] | 0)) {
_________c[m >> 2] = ww(f, Hh((c[(c[p >> 2] | 0) + 56 >> 2] | 0) + ((d[g + 6 >> 0] | 0) + 8) | 0) | 0) | 0;
_________continue
______} else {
_________c[m >> 2] = ww(f, Hh((c[g + 56 >> 2] | 0) + (e[(c[p >> 2] | 0) + 20 >> 1] & (d[(c[(c[p >> 2] | 0) + 64 >> 2] | 0) + (c[n >> 2] << 1) >> 0] << 8 | d[(c[(c[p >> 2] | 0) + 64 >> 2] | 0) + (c[n >> 2] << 1) + 1 >> 0])) | 0) | 0) | 0;
_________continue
______}
___}
___if ((n | 0) == 10) {
______p = k;
______g = c[p + 4 >> 2] | 0;
______f = c[j >> 2] | 0;
______c[f >> 2] = c[p >> 2];
______c[f + 4 >> 2] = g;
______c[h >> 2] = 0;
______f = c[h >> 2] | 0;
______i = l;
______return f | 0
___} else if ((n | 0) == 16) {
______c[h >> 2] = c[m >> 2];
______f = c[h >> 2] | 0;
______i = l;
______return f | 0
___}
___return 0
}

function rz(a, b, d) {
___a = a | 0;
___b = b | 0;
___d = d | 0;
___var e = 0,
______f = 0,
______g = 0,
______h = 0,
______j = 0,
______k = 0,
______l = 0,
______m = 0,
______n = 0;
___f = i;
___i = i + 32 | 0;
___m = f + 28 | 0;
___g = f + 24 | 0;
___k = f + 20 | 0;
___e = f + 16 | 0;
___n = f + 12 | 0;
___j = f + 8 | 0;
___l = f + 4 | 0;
___h = f;
___c[m >> 2] = a;
___c[g >> 2] = b;
___c[k >> 2] = d;
___c[e >> 2] = 0;
___if (!(c[(c[m >> 2] | 0) + 328 >> 2] | 0)) {
______a = c[e >> 2] | 0;
______i = f;
______return a | 0
___}
___c[n >> 2] = 0;
___while (1) {
______if (c[e >> 2] | 0) {
_________g = 15;
_________break
______}
______if ((c[n >> 2] | 0) >= (c[(c[m >> 2] | 0) + 304 >> 2] | 0)) {
_________g = 15;
_________break
______}
______c[j >> 2] = c[(c[(c[m >> 2] | 0) + 328 >> 2] | 0) + (c[n >> 2] << 2) >> 2];
______c[l >> 2] = c[c[(c[j >> 2] | 0) + 4 >> 2] >> 2];
______if ((c[(c[j >> 2] | 0) + 8 >> 2] | 0) != 0 ? (c[c[l >> 2] >> 2] | 0) >= 2 : 0) {
_________d = c[g >> 2] | 0;
_________if ((d | 0) == 2) c[h >> 2] = c[(c[l >> 2] | 0) + 88 >> 2];
_________else if (!d) {
____________c[h >> 2] = c[(c[l >> 2] | 0) + 80 >> 2];
____________c[(c[j >> 2] | 0) + 20 >> 2] = (c[k >> 2] | 0) + 1
_________} else c[h >> 2] = c[(c[l >> 2] | 0) + 84 >> 2];
_________if ((c[h >> 2] | 0) != 0 ? (c[(c[j >> 2] | 0) + 20 >> 2] | 0) > (c[k >> 2] | 0) : 0) c[e >> 2] = zb[c[h >> 2] & 63](c[(c[j >> 2] | 0) + 8 >> 2] | 0, c[k >> 2] | 0) | 0
______}
______c[n >> 2] = (c[n >> 2] | 0) + 1
___}
___if ((g | 0) == 15) {
______a = c[e >> 2] | 0;
______i = f;
______return a | 0
___}
___return 0
}


Original C code:
https://raw.githubusercontent.com/kripken/sql.js/master/c/sqlite3.c

In order to run everywhere, asm.js is forced to use exceptionally odd syntax work around javascript limitations. Look above, see how the code is littered with the bit-wise or operator "|", this is to work around loose typing. Javascript lacks a 1:1 mapping for native data structures, and anyways javascript's object model is intentionally avoided because it's too slow, so instead asm.js uses byte arrays. Technically hacks like this can work to maintain an equivalent state. But most of the original structure gets lost in translation.

Regardless of one's opinion about whether a browser should use asm.js versus a bytecode, I hope we can agree upon these points:

1. Being in javascript does not automatically make it more intelligible.

2. A bytecode that's designed to be used this way could have a better 1:1 representation, which would increase coherency of code & intentions when translating forwards and backwards.

3. Also, in terms of the OP's point about security, using a bytecode instead of javascript doesn't make a difference.

Edited 2015-06-19 02:13 UTC

Reply Score: 4

RE[4]: OMG
by Lennie on Fri 19th Jun 2015 10:10 UTC in reply to "RE[3]: OMG"
Lennie Member since:
2007-09-22

Ahh, the first code looked a bit like it might be hand written and optimized. That is why it looked readable.

Yes, I know the asm.js syntax, not very pretty at all.

And that was going to be my point too. The 'byte code' won't be the same. It won't need all the extra silly asm.js-like workaround code.

So it will be more readable than the asm.js code.

Not saying it will be great. ;-)

Reply Score: 2

RE: OMG
by satai on Thu 18th Jun 2015 19:31 UTC in reply to "OMG"
satai Member since:
2005-07-30

The security is mainly problem of APIs and quality of the runtime, the form of code serialization is secondary.

Reply Score: 2

RE: OMG
by Lennie on Thu 18th Jun 2015 23:22 UTC in reply to "OMG"
Lennie Member since:
2007-09-22

If you had checked the FAQ you'd know it's just a binary representation of the Javascript syntax:

___

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.

https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webass...

Reply Score: 1

RE[2]: OMG
by galvanash on Fri 19th Jun 2015 00:30 UTC in reply to "RE: OMG"
galvanash Member since:
2006-01-25

If you had checked the FAQ you'd know it's just a binary representation of the Javascript syntax:


That is a bit oversimplified. It is not a representation of JavaScript at all.

https://github.com/WebAssembly/design/blob/master/TextFormat.md

"There is no requirement to use JavaScript syntax; this format is not intended to be evaluated or translated directly into JavaScript."


If you compare this:

https://github.com/WebAssembly/design/blob/master/AstSemantics.md

with this:

http://asmjs.org/spec/latest/

You find that the former is largely identical to the later as far as programming model, data types, etc. In other words WebAssembly is an idealized representation of the programming model of asm.js.

As such, it can be converted into JavaScript, because it maps directly to the semantics of the asm.js programming model (same data types, same statements, same mechanism to represent the heap, etc. etc.) But it isn't in and of itself JavaScript at all.

Reply Score: 3

RE[3]: OMG
by Alfman on Fri 19th Jun 2015 02:53 UTC in reply to "RE[2]: OMG"
Alfman Member since:
2011-01-28

galvanash,

As such, it can be converted into JavaScript, because it maps directly to the semantics of the asm.js programming model (same data types, same statements, same mechanism to represent the heap, etc. etc.) But it isn't in and of itself JavaScript at all.


It was javascript's inadequacies that make asm.js so convoluted. WebAssembly is a super-set of asm.js, with capabilities for datatypes and (bounds checked) heap access. From what I can tell, this will allow it to much better represent the original languages without needing to emulate such capabilities using javascript byte arrays.

So it should be trivial to convert asm.js into WebAssembly, but conversion in the other direction from WebAssembly to asm.js will still be a convoluted process because once again the heap & structures have to be reduced to javascript byte arrays.

Reply Score: 2

RE[4]: OMG
by galvanash on Fri 19th Jun 2015 03:55 UTC in reply to "RE[3]: OMG"
galvanash Member since:
2006-01-25

It was javascript's inadequacies that make asm.js so convoluted.


Well yeah... But the asm.js programming model isn't convoluted, its rather mundane. Its translating to a JavaScript representation and all the baggage that entails that results in the convolution.

I'm all for this. I think it is a great idea. I just don't think it is quite on the mark to say JavaScript's inadequacies make asm.js convoluted... The idea of using a rather simple dynamically typed functional language as a compiler target for C/C++? That is convoluted. This WebAssembly thing is definitely much better than that...

Reply Score: 3

RE[5]: OMG
by Alfman on Fri 19th Jun 2015 04:40 UTC in reply to "RE[4]: OMG"
Alfman Member since:
2011-01-28

galvanash,

I'm all for this. I think it is a great idea. I just don't think it is quite on the mark to say JavaScript's inadequacies make asm.js convoluted... The idea of using a rather simple dynamically typed functional language as a compiler target for C/C++? That is convoluted. This WebAssembly thing is definitely much better than that...


Ah ok, I guess it's just the wording that had me confused. I agree that, if by "model" we mean the concepts behind asm.js as an abstraction, then it's fine. As you say, it's the implementation on top of javascript that made it convoluted.

If WebAssembly is any good and pans out, I expect it will find uses outside of the web also, such as spawning new kinds of portable app stores and maybe even portable operating systems.

Reply Score: 2

RE[3]: OMG
by Lennie on Fri 19th Jun 2015 10:14 UTC in reply to "RE[2]: OMG"
Lennie Member since:
2007-09-22

Sorry, instead of Javascript syntax, I should have described it as: Javascript VM AST ( https://en.wikipedia.org/wiki/Abstract_syntax_tree )

Reply Score: 2

RE: OMG
by CaptainN- on Mon 22nd Jun 2015 22:41 UTC in reply to "OMG"
CaptainN- Member since:
2005-07-07

Because minified, obfuscated - and often terribly written, and unstructured - JavaScript isn't a blob?

Get a grip! ByteCode, especially when it implements a standards isn't any different. At all.

Reply Score: 2

OMG
by biffuz on Thu 18th Jun 2015 17:40 UTC
biffuz
Member since:
2006-03-27

Yes, YES, YESSSSS!!!!!!!!!!!!!!!
Finally, _REAL_ programming languages for the web. I've been waiting for this for the last 20 years. I feel I'm going to cry!

Next step: get rid of HTML.

Reply Score: 3

RE: OMG
by Bobthearch on Thu 18th Jun 2015 17:57 UTC in reply to "OMG"
Bobthearch Member since:
2006-01-27

Next step: get rid of HTML.


So all websites would, in essence, be apps? Would that make simple text-and-jpeg web pages load faster, slower, or no difference?

Reply Score: 3

RE[2]: OMG
by biffuz on Thu 18th Jun 2015 18:16 UTC in reply to "RE: OMG"
biffuz Member since:
2006-03-27

No, I mean something that actually lets you design the layout properly.

Reply Score: 2

RE[3]: OMG
by sukru on Thu 18th Jun 2015 20:35 UTC in reply to "RE[2]: OMG"
sukru Member since:
2006-11-19

We have HTML (5) for that. However separating format, layout, and content in HTML requires discipline, and mastery in CSS-fu, which does not happen all too often.

It is quite possible to write structured HTML which layout and format neutral, and use separate CSS files for managing layout (i.e: mobile, print, etc), and format (i.e.: beautify). Of course, so far the only reasonable option for behavior was JavaScript, which could be fixed by this, or similar initiatives.

Edited 2015-06-18 20:35 UTC

Reply Score: 4

RE[4]: OMG
by biffuz on Fri 19th Jun 2015 07:04 UTC in reply to "RE[3]: OMG"
biffuz Member since:
2006-03-27

[q]We have HTML (5) for that. However separating format, layout, and content in HTML requires discipline, and mastery in CSS-fu, which does not happen all too often.[/quote]
And that's exactly the problem. Current HTML layouting is utterly broken. I see web developers at work - they spend hours and hours to design and fix the layout for every damn browser.
And when they're done, someone else comes in and adds something that breaks everything. The situation is bad especially in mobile.

Reply Score: 2

RE[3]: OMG
by Lennie on Thu 18th Jun 2015 23:28 UTC in reply to "RE[2]: OMG"
Lennie Member since:
2007-09-22

You know the web is always evolving, the web has everything it needs in a modern browser for example for building toolkits in an efficient manner:

https://elements.polymer-project.org/

Reply Score: 2

RE[3]: OMG
by NelsonN on Fri 19th Jun 2015 15:48 UTC in reply to "RE[2]: OMG"
NelsonN Member since:
2005-12-20

Yes, and lets get something better than CSS, ditch that non-standard crap. It has been a nightmare since it was introduced.

Reply Score: 1

asm.js
by ebasconp on Thu 18th Jun 2015 19:49 UTC
ebasconp
Member since:
2006-05-09

Questions:

How asm.js and WebAssembly projects are related?

Is WebAssembly the natural (joint effort) evolution of asm.js?

Are they the same idea implemented in a different way?

Will WebAssembly replace asm.js? Does it have different goals?

Reply Score: 3

RE: asm.js
by satai on Thu 18th Jun 2015 20:01 UTC in reply to "asm.js"
satai Member since:
2005-07-30
RE: asm.js
by galvanash on Thu 18th Jun 2015 23:00 UTC in reply to "asm.js"
galvanash Member since:
2006-01-25

How asm.js and WebAssembly projects are related?


asm.js is a strict subset of JavaScript meant to serve as a compilation target for other languages. The end result, however, is still JavaScript. Browsers that understand asm.js can perform certain runtime optimizations, but for the most part it is handled exactly the way all JavaScript is. It also requires a lot of dynamic check code to allow proper execution on engine's that don't support it...

WebAssembly is quite different. It will leverage much of the existing JavaScript infrastructure that exists in browsers (i.e. compilation, module loading, VM components, sandboxing, etc.), but it can avoid a lot of performance robbing stuff by virtue of not requiring parsing, it is directly decoded and feed to the engine's backend compiler. Most of the dynamic check code can be avoided - engines that support it don't need it, and for the rest it can be done by a polyfill.

Is WebAssembly the natural (joint effort) evolution of asm.js?


I would say yes, although I don't know if that is the official stance on things. Most of the same people that were behind asm.js are on board with this, and many who were not are on board as well.

Are they the same idea implemented in a different way?


In a way yes. Fundamentally that both do the same thing and work in similar ways at runtime. Asm.js compiles to JavaScript, WebAssembly compiles to an abstact sytax tree optimized for compiling to bytecode. It essentially skips a step in the process (or at the least changes a step and makes it much cheaper).

Will WebAssembly replace asm.js? Does it have different goals?


Imo yes, assuming it works as intended. It has all the same benefits, eliminates many of the former's weaknesses, and by virtue of what it is should be much more amiable to optimization and future extensions.

Reply Score: 3

1997 called...
by bryanv on Thu 18th Jun 2015 23:17 UTC
bryanv
Member since:
2005-08-26

It wants it's terrible idea back.

Anyone remember java applets?

The horror.

Reply Score: 3

RE: 1997 called...
by ebasconp on Fri 19th Jun 2015 04:01 UTC in reply to "1997 called..."
ebasconp Member since:
2006-05-09

IAnyone remember java applets?


A lot of differences here:

* It will let native and legacy apps to run inside the browser (opening the possibility to run games in any platform at minimum cost). Porting of legacy applications to web environments can be delayed/postponed.

* It will run the bytecodes inside the JavaScript sandbox; so it is inherently more secure than Java applets.

* It will use all the JavaScript infrastructure that already exists.

Reply Score: 2

RE: 1997 called...
by biffuz on Fri 19th Jun 2015 07:10 UTC in reply to "1997 called..."
biffuz Member since:
2006-03-27

Yup. I liked those. It took 15 years for javascript to reach the same functionality and speed (as in "javascript needs a Core 2 to equal the speed of Java on a Pentium 2"). The only real thing missing from Java applets was the integration with the DOM.

Reply Score: 2

RE[2]: 1997 called...
by Lennie on Fri 19th Jun 2015 10:16 UTC in reply to "RE: 1997 called..."
Lennie Member since:
2007-09-22

Loading speed was and still is a problem of Java.

Look at how long it takes for a Java application to start.

Reply Score: 4

The right way
by dorin.lazar on Fri 19th Jun 2015 03:28 UTC
dorin.lazar
Member since:
2006-12-15

I think this is finally a step into making the Web civilized.

This is not your 1997 Java Applets thing. This is bytecode done after 20 years of experience in bytecode and with bytecode running successfully in a protected environment on all the mobile platforms. This is done with the horrible experience of JavaScript, which I want forgotten for the rest of eternity. JavaScript is the things that horrifies me the most, and all I can say is "Good riddance".

WASM is, in my own view, the big four of browser market getting together to improve the darned thing. Just like HTTP/2 it drops the human readable element for the computer readable element, the idea being that if a computer can read it, it can translate it for you. It's a step towards really using the power of the present-day processors, not copying text and mapping text to code, which is the most that JS does.

And JS is a horrible language. I'm looking forward to writing C++ and C# code for the web, and be confident that it reaches all the users in the world. Finally.

Reply Score: 2

Apple involved?
by RobG on Fri 19th Jun 2015 14:34 UTC
RobG
Member since:
2012-10-17

The project is initiated by dev's from MS, Mozilla and Google. I think taking a WebKit Bug report requesting support as "being worked on by" is stretching it a bit.

I hope you're right, I really hope so, but after the PointerEvents fiasco I don't have much confidence in that.

Reply Score: 2

Yet another Bytecode to replace Java
by DeepThought on Fri 19th Jun 2015 17:24 UTC
DeepThought
Member since:
2010-07-17

Didn't Java start like this? The ultimate Web language? Compile once, run everywhere?
I doubt that another byte code will solve future problems. And most likely, they will have to search a lot to find today's problems this new thing.

Why do web pages load slowly? Because >60% of the content is rubbish like animated advertisement.

Reply Score: 2

Even with JIT...
by deathshadow on Sun 21st Jun 2015 11:58 UTC
deathshadow
Member since:
2005-07-12

1) It is NOT Assembly, even CALLING it Assembly is ignorant halfwit nonsense and insulting to anyone who ever actually learned machine language. As someone who started out hand assembling my own RCA 1802 machine language and entering it on toggle switches -- and who STILL writes 8088 and 6502 machine language today -- them even using the term borders on offensive!

Is it processor specific? Is it using opcodes that ACTUALLY correspond to hardware specific machine language instructions? NO? THEN IT'S NOT ASSEMBLY!!!

Just like the "virtual machine" BS, it's an interpreter that may someday have a JIT compiler. It's bad enough Java went and made up some BS claims about what it is, without this "new" technology abusing a term that has little if anything to do with what it is. ... and yes, that's me making air quotes with my fingers around "new"

It's ALMOST as ignorant as the nitwits who call XML a "machine readable format" or think that base64 is a native efficient storage method. (the latter only being true if you're still on a PDP-11) -- Makes those of us who actually understand these terms and used them when they MEANT SOMETHING feel like delivering a pimp slap to the current generation.

Hell, given some of the idiocy I've seen cross-processor transcoders and P-Code interpreters do, and the history of BS claims about speed from previous attempts (like Java) that still have zero basis in reality, I'm not entirely hopeful on this.

That said, it's about damned time there was a bytecode transmission method for scripttardery; except for one little problem.

2) the LAST thing we need right now is MORE scripttard BS pissing away functionality, bandwidth and accessibility of websites. IT's bad enough people crapping all over their websites with mouth-breathing idiocy like jQuery and ignoring the very reason HTML and CSS even exist with dumbass bull like bootcrap, without giving them YET ANOTHER way to add "gee ain't it neat" nonsense to websites like all the other web crapplet asshattery that has effectively made websites today a fraction as useful and often slower than they were 20 years ago.

But of course, such sensibilities are lost upon the mouth-breathing halfwits sleazing together websites any-old-way with shortcuts and outright scam artist bull like Turdpress, bootcrap and jQueery -- since they see nothing wrong with wasting 3 megabytes in six to eight dozen separate files to deliver 5k of plaintext and a dozen content images that shouldn't even total 128k.

Of course, they'll probably also use the SCRIPT tag for it or want their own tag, just like the idiotic redundancies that the 5-tard bull introduced with AUDIO and VIDEO, instead of using the tag meant to fight vendor lock-in called OBJECT. Yay for bleeding edge of pre-strict coding methodologies! Nothing like dragging everything back to the WORST of the 1997 to 2000 browser wars.

3) ... and get off my damned lawn!

Edited 2015-06-21 11:59 UTC

Reply Score: 2

RE: Even with JIT...
by Alfman on Sun 21st Jun 2015 16:56 UTC in reply to "Even with JIT..."
Alfman Member since:
2011-01-28

deathshadow,

Wow, what a rant... haha it made me laugh! You are right, it's not really assembly, rather it is a bytecode. I'd be for calling it "web bytecode" maybe.


That said, it's about damned time there was a bytecode transmission method for scripttardery...


True. Assuming this gains traction (which is not a given), it will help balance the playing field instead of giving javascript a defacto monopoly, which is good.


2) the LAST thing we need right now is MORE scripttard BS pissing away functionality, bandwidth and accessibility of websites. IT's bad enough people crapping all over their websites with mouth-breathing idiocy like jQuery and ignoring the very reason HTML and CSS even exist with dumbass bull like bootcrap, without giving them YET ANOTHER way to add "gee ain't it neat" nonsense to websites like all the other web crapplet asshattery that has effectively made websites today a fraction as useful and often slower than they were 20 years ago.


I'm not so sure that things are slower (given the rapid technological advancement). But if they are, it's probably just because we're transferring so many more resources than before. Even just a plain vanilla HTML/CSS website can get resource heavy. And moving things into the client can and sometimes does help save a lot of the overhead going on between the client and server. So I believe we'd be in the same boat regardless of scripting.

Now with this said, when scripts are abused they clearly have the potential to make things much worse. My favorite parts store (newegg) has been using more and more scripting to control the experience, which has me going to alternatives because their scripts are so damned buggy. Some navigation links use javscript to update the contents, which gets refreshed but the "loading divs" aren't deleted afterwards and occlude the new page contents. Very frequently the product image browser breaks with javascript errors. I would gladly take their website from two years ago over this new piece of garbage.

Edited 2015-06-21 17:06 UTC

Reply Score: 2

PyPy.js, java and company in a browser
by troy.unrau on Sun 21st Jun 2015 18:43 UTC
troy.unrau
Member since:
2007-02-23

I'm actually looking forward to this. A lot of languages already compile to bytecode in various ways: java and python being the two that I use regularly. They always need some bytecode interpreter or vm or some equivalent that is domain specific. If this gets supported by all the major browsers, I'd be willing to wager that projects like PyPy.js are abaondonned in favour of directly compiling to the new bytecode. Essentially, we're going to have a browser standard bytecode interpreter that all the compilers can target. So Yay!

And with google involved, and their experience with Dalvik and ART, they'll probably find a way to compile Java directly to this bytecode as well. Which, I'd wager, means Oracle probably gets cut out of the Java ecosystem for browser plugins. So no more Ask toolbar bullshit.

Reply Score: 2