5 ms·

So what does the future hold? Will this replace JavaScript?

JoshTriplett 10y ago
In the short term: probably not for small glue scripts, but it'll provide a serious alternative for larger web applications. In the long term, we might see WebAssembly used as a means to implement JavaScript, such that you can count on the same set of features in every browser. That'll depend on how well WebAssembly can interface with the DOM and with other browser APIs without needing JavaScript shim layers.
- EamonnMR 10y ago
  The point about having a nice API is huge-otherwise we'd still be writing java applets.
  - pekk 10y ago
    Intel x86 assembler is arguably not a nice API, but most of us are not working at that level any more. The requirements for an instruction set aren't really the same as the requirements for a language well suited to writing, say, video poker games.
oblio 10y ago
I don't get why people are so excited about WebAssembly, at least on the whole "replace Javascript"/"remove web bloat" aspect. Right now we have Javascript and its assorted libraries, which, as bad as they are, come with the browser or at least are generally reused/cached very frequently. People seem to fail to realize that everyone and their mother will dump their runtimes and their VMs on top of WebAssembly as soon as they will be able to. Java Applets 1, 2, ..., 100. Yes, they will present it in a very fancy and attractive way, but fundamentally that's what will happen, cause who wants to rewrite everything for Javascript-land when they're not forced to? Competitive pressure will always push towards bloat, just look at Facebook and they Android-runtime busting app for an example. I, for one, am looking forward to the day where, besides the 500MB of Javascript my 40 tabs are loading, I'll also load 1.5 GB of WebAssemblied formerly native runtimes.
- s369610 10y ago
  I doubt it will be for average brochure sites, but I have used it in two situations, one to encode a series of captured canvas frames into ogg video on the client using ffmpeg to save bandwidth on a telehealth web application, and another to embed a mobile game engine in with samples so users can interact in the browser without having to download build and run http://moaiforge.com/samples/sample-browser/player/index.html#hello-moai http://moaiforge.com/samples/sample-browser/player/index.htm...
- tromp 10y ago
  I'm excited at the prospect of 64-bit integer support, which will significantly speed up many applications, making even web-based proof-of-work mining feasible.
  - rspeer 10y ago
    Wait. Why would you want web-based proof-of-work mining? Does this have a legitimate purpose, or is it all about forcing unsuspecting visitors to mine Bitcoin for you?
    - drchickensalad 10y ago
      For things that are DOS-sensitive
    - tromp 10y ago
      The web page should only start the miner if the user is well informed and clicks a button to start it. Legitimate purposes include spam-proofing message boxes, as well as cryptocurrencies whose PoW is somewhat CPU friendly, such as those bottlenecked by DRAM latency.
- Someone 10y ago
  JavaScript got at least part of its popularity because it was the only thing that ran in all clients (Flash and Java were close, but had the disadvantage of being owned by a single big player) Similarly, node.js got at least part of its popularity because it was the only thing that used _the_ language you can also run in the client. This levels that playing field at least a bit (completely, if it can manipulate the DOM with little friction) I expect to see many server-side languages will fairly soon compile to WebAssembly, so that they can position themeselves as an alternative to node (For example, I think Apple would be stupid if it wasn't working on a Swift-to-WebAssembly compiler). In my book, that is good; competition in that field will improve all tools.
tannhaeuser 10y ago
The more imminent concern is that publishers are beginning to bundle browser runtimes completely replacing native browser functionality along with its established privacy and fair use expectations. Say hello to unskippable interstitials, unblockable analytics and targeted advertising, content that can't be linked, saved/archived, mirrored, cached, shared, translated or made otherwise accessible. Developers mostly discuss JavaScript shortcomings and new possibilities offered by WebAss, but seem otherwise happy to completely throw the fundamental architecture of the web under the bus. Technically, what WebAss can do has since long been possible with native applications; the only thing added here are new software licensing models, eg. pay-per-use, but mostly tracking/ad-financed.
- vertex-four 10y ago
  Or... you could continue avoiding websites that do what you deem unacceptable things. I won't visit a Forbes website intentionally - I have no intention of supporting a site that wants to throw ads quite that blatantly in my face. There'll always be a very large amount of sites that behave respectably.
  - tmccrmck 10y ago
    What sites do you frequent? Almost every site is infested with advertising.
- pekk 10y ago
  This isn't a dystopian future we can avoid, it is a dystopian present that already happened and we are stuck with it. Almost every page needs JS to use. Almost all JS is thoroughly munged beyond readability. It's normal for even page navigation (surely a browser function) to be handled in JS, and for resource loading (again a browser function) to be done through JS making AJAX requests to URLs generated deep in a minified blob. The accessibility nightmare is real. Ads are common as ever and adblocking is an arms race never won. DRM has been here for years, and HBO isn't putting .mp4s on an FTP server any time soon. YouTube is almost unwatchably saturated with ads and is run by Google, the search and analytics company. Targeted advertising and analytics are a bell that can't be un-rung. The web you are trying to save became a victim of its own success, somewhere around when everyone decided it was going to be HTTP and HTML instead of gopher, the browser wars started and AOL users started to flood USENET.
tomatsu 10y ago
> Will [Wasm] replace JavaScript? For bigger games, maybe. For applications, not so much. However, it will give you the ability to mix and match different languages more freely. E.g. you can write processing-intensive modules in Rust/C/C++ and continue to script the UI with JS/TS/Dart. This way you won't have to recompile tens or even hundreds of thousands of lines of code for minor UI changes.
tyingq 10y ago
WebAssembly does have GC, Polymorphic Inline Cache, and direct DOM integration on their roadmap. So, at some point, you should be able to compile any language to WASM, including Javascript. The only real barrier would be the size of the runtime / standard library for the language. If WASM supports also supports some kind of hashed cache where many sites can share a language runtime, that's not even much of a barrier. I suspect once it's stable, you'll see all sorts of languages being used in the browser.

In the short term: probably not for small glue scripts, but it'll provide a serious alternative for larger web applications. In the long term, we might see WebAssembly used as a means to implement JavaScript, such that you can count on the same set of features in every browser. That'll depend on how well WebAssembly can interface with the DOM and with other browser APIs without needing JavaScript shim layers.

EamonnMR 10y ago
The point about having a nice API is huge-otherwise we'd still be writing java applets.
- pekk 10y ago
  Intel x86 assembler is arguably not a nice API, but most of us are not working at that level any more. The requirements for an instruction set aren't really the same as the requirements for a language well suited to writing, say, video poker games.

oblio 10y ago

I don't get why people are so excited about WebAssembly, at least on the whole "replace Javascript"/"remove web bloat" aspect. Right now we have Javascript and its assorted libraries, which, as bad as they are, come with the browser or at least are generally reused/cached very frequently. People seem to fail to realize that everyone and their mother will dump their runtimes and their VMs on top of WebAssembly as soon as they will be able to. Java Applets 1, 2, ..., 100. Yes, they will present it in a very fancy and attractive way, but fundamentally that's what will happen, cause who wants to rewrite everything for Javascript-land when they're not forced to? Competitive pressure will always push towards bloat, just look at Facebook and they Android-runtime busting app for an example. I, for one, am looking forward to the day where, besides the 500MB of Javascript my 40 tabs are loading, I'll also load 1.5 GB of WebAssemblied formerly native runtimes.

s369610 10y ago
I doubt it will be for average brochure sites, but I have used it in two situations, one to encode a series of captured canvas frames into ogg video on the client using ffmpeg to save bandwidth on a telehealth web application, and another to embed a mobile game engine in with samples so users can interact in the browser without having to download build and run http://moaiforge.com/samples/sample-browser/player/index.html#hello-moai http://moaiforge.com/samples/sample-browser/player/index.htm...
tromp 10y ago
I'm excited at the prospect of 64-bit integer support, which will significantly speed up many applications, making even web-based proof-of-work mining feasible.
- rspeer 10y ago
  Wait. Why would you want web-based proof-of-work mining? Does this have a legitimate purpose, or is it all about forcing unsuspecting visitors to mine Bitcoin for you?
  - drchickensalad 10y ago
    For things that are DOS-sensitive
  - tromp 10y ago
    The web page should only start the miner if the user is well informed and clicks a button to start it. Legitimate purposes include spam-proofing message boxes, as well as cryptocurrencies whose PoW is somewhat CPU friendly, such as those bottlenecked by DRAM latency.
Someone 10y ago
JavaScript got at least part of its popularity because it was the only thing that ran in all clients (Flash and Java were close, but had the disadvantage of being owned by a single big player) Similarly, node.js got at least part of its popularity because it was the only thing that used _the_ language you can also run in the client. This levels that playing field at least a bit (completely, if it can manipulate the DOM with little friction) I expect to see many server-side languages will fairly soon compile to WebAssembly, so that they can position themeselves as an alternative to node (For example, I think Apple would be stupid if it wasn't working on a Swift-to-WebAssembly compiler). In my book, that is good; competition in that field will improve all tools.

tannhaeuser 10y ago

The more imminent concern is that publishers are beginning to bundle browser runtimes completely replacing native browser functionality along with its established privacy and fair use expectations. Say hello to unskippable interstitials, unblockable analytics and targeted advertising, content that can't be linked, saved/archived, mirrored, cached, shared, translated or made otherwise accessible. Developers mostly discuss JavaScript shortcomings and new possibilities offered by WebAss, but seem otherwise happy to completely throw the fundamental architecture of the web under the bus. Technically, what WebAss can do has since long been possible with native applications; the only thing added here are new software licensing models, eg. pay-per-use, but mostly tracking/ad-financed.

vertex-four 10y ago
Or... you could continue avoiding websites that do what you deem unacceptable things. I won't visit a Forbes website intentionally - I have no intention of supporting a site that wants to throw ads quite that blatantly in my face. There'll always be a very large amount of sites that behave respectably.
- tmccrmck 10y ago
  What sites do you frequent? Almost every site is infested with advertising.
pekk 10y ago
This isn't a dystopian future we can avoid, it is a dystopian present that already happened and we are stuck with it. Almost every page needs JS to use. Almost all JS is thoroughly munged beyond readability. It's normal for even page navigation (surely a browser function) to be handled in JS, and for resource loading (again a browser function) to be done through JS making AJAX requests to URLs generated deep in a minified blob. The accessibility nightmare is real. Ads are common as ever and adblocking is an arms race never won. DRM has been here for years, and HBO isn't putting .mp4s on an FTP server any time soon. YouTube is almost unwatchably saturated with ads and is run by Google, the search and analytics company. Targeted advertising and analytics are a bell that can't be un-rung. The web you are trying to save became a victim of its own success, somewhere around when everyone decided it was going to be HTTP and HTML instead of gopher, the browser wars started and AOL users started to flood USENET.

tomatsu 10y ago

> Will [Wasm] replace JavaScript? For bigger games, maybe. For applications, not so much. However, it will give you the ability to mix and match different languages more freely. E.g. you can write processing-intensive modules in Rust/C/C++ and continue to script the UI with JS/TS/Dart. This way you won't have to recompile tens or even hundreds of thousands of lines of code for minor UI changes.

tyingq 10y ago

WebAssembly does have GC, Polymorphic Inline Cache, and direct DOM integration on their roadmap. So, at some point, you should be able to compile any language to WASM, including Javascript. The only real barrier would be the size of the runtime / standard library for the language. If WASM supports also supports some kind of hashed cache where many sites can share a language runtime, that's not even much of a barrier. I suspect once it's stable, you'll see all sorts of languages being used in the browser.