All Major Browsers Now Support WebAssembly

Following the adoption by Safari and Edge, all major browsers now support WebAssembly, which delivers JavaScript code compiled as highly-optimized bytecode. Bytecode, being many times smaller than the code from which it's been compiled, can be used to save bandwidth on mobile devices and help improve page loading times for modern websites and web apps.

Even from the day of the announcement, WebAssembly was insanely popular with the online gaming industry who could create more advanced gaming engines, similar to the ones used for desktop-based games. All these positive features and potential gains were why Mozilla engineers called the feature a "game changer for the web," and why work on WebAssembly went much smoother and faster than many could have predicted.

Better web mining clients is what I see.

Been a few years since I was working with this but here goes:

in normal operation javascript is sent as source code to the browser which then has to compile, then interpret the resulting Java bytecode using the platform's runtime. What webassembly does is send down precompiled java object code. The fact that the browser does not have to call java to compile the javascript code is what saves time and bandwidth. I have run into situations where java bytecode from one version of java is not compatible across java versions (i.e. some java 1.6 byte code is not compatible with Java 1.7 without special jvm execution options).

When sending source javascript to the browser this version incompatibility is not a problem because the client compiles it. However I am not sure how WebAssembly gets around this possible versioning issue. Perhaps WebAssembly has its own jvm runtime?

Where are you reading that Java/JVM is involved at all?

cyberguyz said:

Been a few years since I was working with this but here goes:

in normal operation javascript is sent as source code to the browser which then has to compile, then interpret the resulting Java bytecode using the platform's runtime. What webassembly does is send down precompiled java object code. The fact that the browser does not have to call java to compile the javascript code is what saves time and bandwidth. I have run into situations where java bytecode from one version of java is not compatible across java versions (i.e. some java 1.6 byte code is not compatible with Java 1.7 without special jvm execution options).

When sending source javascript to the browser this version incompatibility is not a problem because the client compiles it. However I am not sure how WebAssembly gets around this possible versioning issue. Perhaps WebAssembly has its own jvm runtime?

Click to expand...

Java /= javascript

Completely different things.

Sorry. Brainfart. I did say it has been a few years...
Anyhow there are similarities between both languages - each has to be compiled to bytecode. Before webassembly it is done by the client. After webassembly it is precompiled. both have to be executed by an interpreter (vm). Disregard my ruminations on versioning since it has nothing to do with the way ecma versions are handled.

Though completely different languages, Javascript takes its internal syntax from Java (inside the script tags).

cyberguyz said:

Sorry. Brainfart. I did say it has been a few years...
Anyhow there are similarities between both languages - each has to be compiled to bytecode. Before webassembly it is done by the client. After webassembly it is precompiled. both have to be executed by an interpreter (vm). Disregard my ruminations on versioning since it has nothing to do with the way ecma versions are handled.

Though completely different languages, Javascript takes its internal syntax from Java (inside the script tags).

Click to expand...

Sorry, no. The only connection between Java and JavaScript is the name due a marketing brainfart from Netscape. They were made by different companies at different moments for different reasons.

Just to clear up some confusion: Javascript is one implementation of ECMAScript. Javascript is usually rapidly (JIT) compiled into bytecode, which runs on a Virtual machine (VM) with optimized access to native instructions on your local architecture. (Coincidentally, lots of languages operate on this same sort of principal, unfortunately one of them is named very similarly: Java.)

I'll explain what WebAssembly is:

* It is a bytecode language (called WASM). Yes, another one. As the news article states, now all the major browsers have agreed on the instruction set to include in their own VM. Some sort of ECMAScript implementation bytecode is now extended with WASM bytecode.
* Each browser has an interface to access the compiled WASM bytecode and memory via exports.
* WASM bytecode can be translated and represented in an intermediary language called WAST. It's just a more readable version of the bytecode.
* The WASM compiler which generates bytecode blobs currently supports C/C++ and Rust as an input language, and additional translators are developed independently and are independent of the browser software.

So, you can now write some javascript, provide it with your website, browser JIT compiles to VM bytecode, and runs.

OR, you can now write some C, compile it to WASM bytecode, provide it with your website (along with some controlling javascript, which is JIT compiled to VM bytecode), and runs.

Oh, and the compiler and VM can't really handle much outside of the most basic forms of programming (basic logic, branches, io). There's a list of what's being worked on here: http://webassembly.org/docs/future-features/

Now web pages can consume more of your memory in less time and be stealthier as well.... FTW!

Tried the tank demo and OoM .... hardware acceleration was the problem ...

The performance gains should be huge. Security is about to get black hard, though. This is the true Flash successor hehe

dgz said:

The performance gains should be huge. Security is about to get black hard, though. This is the true Flash successor hehe

Click to expand...

I was thinking the exact same thing. As a security professional, it's hard not to see vulnerabilities as the result of new technology.

Flapjack said:

I was thinking the exact same thing. As a security professional, it's hard not to see vulnerabilities as the result of new technology.

Click to expand...

We web devs are going to need you more than ever. Securing systems is hard and we suck at it