WebAssembly support now shipping in all major browsers

Post by saosebastiao » Tue, Nov 14, 2017, 5:05 PM UTC

themihai wrote: post #187

rhabarba wrote: post #184

WebAssembly is not worth the effort unless it finally is supported by the LINK tag. Seriously, using JS to load a JS alternative is ridiculous.

I can't agree more...but I believe the issue is that WASM sold a lie. Right now if you read between the lines it is argued that WASM is there just to help JS do more not to replace it.

Post by vanderZwan » Tue, Nov 14, 2017, 5:08 PM UTC

esrauch wrote: post #171

vanderZwan wrote: post #170

Aside: how is WebAssembly's binary form currently shipped? In a demo I saw yesterday it was written out inline as a Uint8Array of integers between 0-255. Even with gzip enabled this can't be very efficient. For completely unrelated reasons, I was already thinking of adapting (my fork of) the LZ-string library[0] to directly compress/decompress typed arrays to "websafe" UTF16 strings, similar to the already existing `…

wasm files are already a binary format, an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.

    fetch('simple.wasm').then(response =>
      response.arrayBuffer()
    ).then(bytes =>
      WebAssembly.instantiate(bytes, importObject)
    ).then(results => {
      results.instance.exports.exported_func();
    });

Post by ravenstine » Tue, Nov 14, 2017, 5:15 PM UTC

Klathmon wrote: post #179

greenhouse_gas wrote: post #174

Earlier quoted context omitted.

There's another reason why I want JavaScript in the browser to die: We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there. Why? It's simply too expensive to create a fast (and compatible) JS engine. If Web…

I completely disagree that the issue is JavaScript here. In my opinion, the issue is the DOM. It's API is massive, there is decades of cruft and backwards compatibility to worry about, and it's codebase is significantly larger in all major open source browsers out there.

Post by Seanny123 » Tue, Nov 14, 2017, 5:20 PM UTC

chkuendig wrote: post #8

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not havi…

Post by romaniv » Tue, Nov 14, 2017, 5:24 PM UTC

foodstances wrote: post #153

sametmax wrote: post #147

Earlier quoted context omitted.

In corporate env it is.

Either the computers in these mysterious corporate environments are exposed to the internet, in which case they'd be reflected in these public stats collected by them visiting public websites from IE, or they aren't, in which case they don't matter in the slightest because they're not going to visit webpages using WebAssembly.