Slashdot Mirror

← Back to Stories (view on slashdot.org)

Will WebAssembly Replace JavaScript? (medium.com)

Posted by EditorDavid on from the WebAssembly-language dept.

On Tuesday Firefox 52 became the first browser to support WebAssembly, a new standard "to enable near-native performance for web applications" without a plug-in by pre-compiling code into low-level, machine-ready instructions. Mozilla engineer Lin Clark sees this as an inflection point where the speed of browser-based applications increases dramatically. An anonymous reader quotes David Bryant, the head of platform engineering at Mozilla. This new standard will enable amazing video games and high-performance web apps for things like computer-aided design, video and image editing, and scientific visualization... Over time, many existing productivity apps (e.g. email, social networks, word processing) and JavaScript frameworks will likely use WebAssembly to significantly reduce load times while simultaneously improving performance while running... developers can integrate WebAssembly libraries for CPU-intensive calculations (e.g. compression, face detection, physics) into existing web apps that use JavaScript for less intensive work... In some ways, WebAssembly changes what it means to be a web developer, as well as the fundamental abilities of the web.
Mozilla celebrated with a demo video of the high-resolution graphics of Zen Garden, and while right now WebAssembly supports compilation from C and C++ (plus some preliminary support for Rust), "We expect that, as WebAssembly continues to evolve, you'll also be able to use it with programming languages often used for mobile apps, like Java, Swift, and C#."

11 of 235 comments (clear)

  1. No by Anonymous Coward · · Score: 5, Informative

    From the web assembly web page:

    Is WebAssembly trying to replace JavaScript?

    No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web....

    1. Re:No by Xtifr · · Score: 5, Informative

      It's being developed by Microsoft, Google, Apple, and Mozilla, and has been demoed in beta versions of Chrome and MS-Edge already. Mozilla is merely the first out the door with an official release.

  2. Re:Hard to argue against Betteridge here by luismontbau · · Score: 5, Informative

    Well, Google Chrome 57 also incorporates WebAssembly, and soon, so will Safari and Edge. If you're interested in the future of the web, I suggest you read all the articles, they are quite interesting. I think it's the only chance the open web has against walled app gardens.

  3. Chrome too by campuscodi · · Score: 5, Informative

    Google also officially added support for WebAssembly in Chrome 57, released 3 days ago, btw

  4. JS "programmers" are too incompetent for that by gweihir · · Score: 4, Informative

    WebAssembly will primarily allow real coders to write applications that run in browsers. No JavaScript wannabees need to apply.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  5. Re: Native code running in the Browser? by Zero__Kelvin · · Score: 3, Informative

    This has nothing to do with Active X, and furthermore your implication that if Microsoft tried and failed at something then nobody else need try is absurd.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  6. Re:Native code running in the Browser? by Anonymous Coward · · Score: 2, Informative

    No, Native Speed. Not native code. It can't do things javascript doesn't do, it does things javascript can do, but much faster.

  7. Looks good to me by steveha · · Score: 5, Informative

    I read through the fine articles and even watched a couple of the videos. Overall this looks like a good idea to me.

    The basic idea: WebAssembly is an assembly language for a virtual machine, which is very easy to translate into native code. It was designed to be compact so it will download quickly; in particular they chose a stack-based virtual architecture so that an "ADD" instruction implicitly adds the top two numbers on the stack, so "ADD" and similar operations are always single bytecodes. Also, while JavaScript only has a single "number" type which is implicitly float, WebAssembly has multiple built-in native types including 64-bit integer.

    It should be no less secure, and no more secure, than JavaScript. However almost all the overhead of an interpreted language is gone: instead of just-in-time compilation, detecting "hot spots" and optimizing, and de-optimizing when assumptions are invalidated, all the browser has to do is translate the virtual machine code into native code and run it.

    For the initial release (i.e. right now) WebAssembly does not support garbage collection. This is a sensible decision given what it is and what it does, but they said they will look at giving it some GC abilities in future releases.

    I like the original idea that JavaScript would always be human-readable and people could learn by studying the code from the sites they visit. However, this idea is not really active now. It's common practice to run JavaScript code through a "minifier" that packs it to make it as small as possible so it will load quickly, and minified code isn't very friendly to read. There are tools available to somewhat beautify minified JS, but I'm certain that there will be tools to "decompile" WebAssembly and produce something sort-of readable. So while in this one area WebAssembly is not quite as nice as JavaScript, I don't think it's a significant thing, and it's not even remotely enough to make me oppose WebAssembly.

    Developers will be able to take existing code in languages like C, C++, etc. and compile them into this portable virtual machine language, and web browsers will be able to load and run them quickly. People will be able to write browser apps that run at near-native-speed and they will run on all the major web browsers and on whatever CPU you have (x86 and ARM for now). I don't really see a downside and I see lots of upside.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:Looks good to me by steveha · · Score: 3, Informative

      the small benefit of JavaScript is that we can disable it and/or prevent certain function calls if you want to (e.g. my browser asks me if alert() is allowed to trigger or intercepts audio() and video() tags etc etc.

      All I know about WebAssembly is what I read in TFA but I'll bet you that it will still be possible to block API calls exactly the same way. In fact, if my understanding is correct, WebAssembly doesn't come with any API calls; it will need to ask JavaScript to do things like pop up an alert().

      Here, have a link I Googled up for you. Here's you you do an alert() from WebAssembly: you import alert() from JavaScript and call that.

      https://gist.github.com/cure53/f4581cee76d2445d8bd91f03d4fa7d3b

      So whatever you are doing right now to forbid alert() would continue to work when your browser downloads WebAssembly code.

      If you're going to obfuscate calls even further into machine code and allow for code to run directly on a CPU and manipulate memory without the capacity for inspection, you've given up all control.

      I've already made my position on that clear. Bytecode is less readable than minified JS but not by that much.

      Plus I don't actually pick apart all the minified JS my browser is running and inspect it in advance. And I figure with GMain and such my browser is running a lot of minified JS.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    2. Re:Looks good to me by steveha · · Score: 3, Informative

      allow for code to run directly on a CPU and manipulate memory

      I missed this the first time around. WebAssembly is sandboxed exactly like JavaScript is. It is neither more secure nor less secure than JavaScript.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  8. Inner Platform Effect by CnlPepper · · Score: 3, Informative

    I'm just going to leave this here: https://en.wikipedia.org/wiki/...

    If you want native speeds, use the OS. This is doing nothing more than complicating development - now rather than just OS differences you have every possible permutation of OS and browser to deal with when bug fixing.