Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Software Chrome Firefox Google Microsoft Mozilla Safari Apple

Major Browsers Add Experimental Support For WebAssembly ( 118

An anonymous reader writes: Four major web browsers have announced support for the near-native compiling technology WebAssembly, and collaborated to bring an initial common game demo of Angry Bots, running via Unity and WebAssembly, to experimental builds of Chrome, Firefox, Microsoft Edge and, shortly, Safari. WebAssembly was launched last year in a joint project between Microsoft, Mozilla, Apple and Google as a potentially more efficient route to assembly-level performance than asm.js, which is in itself a low-level subset of JavaScript.
This discussion has been archived. No new comments can be posted.

Major Browsers Add Experimental Support For WebAssembly

Comments Filter:
  • >> assembly-level performance (from Javascript)

    You keep using that word, I do not think it means what you think it means.
  • by Anonymous Coward

    Now this?????

    • by beelsebob ( 529313 ) on Tuesday March 15, 2016 @01:49PM (#51701537)

      Right, now we have an open standard byte code that any language can target, and any browser can implement, along with several competing implementations, and lots of eyes looking at the security of those implementations.

      So yeh... HELL YEH, NOW THIS!!!!

      • by vivaoporto ( 1064484 ) on Tuesday March 15, 2016 @01:58PM (#51701609)

        and any browser can implement

        Up until someone finds a way to introduce either a patent encumbered functionality (like H264) or one inherently proprietary (like EME for DRM) to poison the well and keep real independent implementations out of scope for everybody else except the incumbents.

      • Right, now we have an open standard byte code that any language can target, and any browser can implement, along with several competing implementations, and lots of eyes looking at the security of those implementation

        Flash was an open standard byte code (well documented too) with at least once complete F/OSS implementation.

        The difference is now ads in JS can bypass the easy "do not play Flash except from whitelist" method of killing nasty ads.

        several competing implementations

        For the love of holy things, wh

        • For the love of holy things, why would I want multiple competing, incompatible, implementations of a programming runtime environment?

          Because you remember what a single-browser hegemony was like and you don't want us to go through that again.

          • Runtimes != Browser. See, Chrome, Chromium, Opera and others.

            Also, IE6 was bad because it didn't play well with established standards, and was greedy of MS, but it wasn't actually horrible.

            • That's somewhat revisionist. IE 3-6 when they were released were much more standards compliant than other browsers, particularly Netscape Navigator. (Layer tags, seriously?) IE was the first browser to fully comply with CSS1. The problem was that once IE6 was out they had so far outpaced their competitors (and abused their monopoly position) that there was no more competition, and since Microsoft was not a web company and had no interest in seeing the web advance, they did nothing for years. Of course years

        • Because when there's only one single, or a very few implementations, that implementation gets rapidly stale and shitty.

          See for example, Flash, and Java, or just with generic web techs... IE.

          Add two implementations of generic web techs (i.e. Gecko and WebKit), and suddenly the quality has gone sky high.

          • Flash had at least three implementations: Flash, Gnash and a Mozilla one. I believe Google also implemented a Flash runtime for embedded Chrome.

            It's a fucking platform. Why shouldn't it get stale? You say stale; I hear "stable"

  • by Anonymous Coward

    This is awesome. Bring it on.

    Last month I saw a JS x86 virtual machine running DOS and windows 98 in a chrome tab.

    That is fucking awesome. Need some special feature that no browser will support? Fuck it. Ship your own weird pseudo micro-OS and have your web application load it up on the fly.

    I remember my first time on the internet. Someone set up Next stations in the Exporatorium in San Francisco. This is when the www was just a handful of web pages.

    My first internet at home was on a 3.11 machine with dialu

    • I miss my 2400 baud modem hooked up to my Radio Shit computer with my 40x24 display. Now get off my lawn!

    • And your 64bit quad core smartphone and modern computer have been thoroughly cracked by hackers at record speed. Progress!
    • by qbast ( 1265706 )
      Fucking awesome! All the speed of Pentium 100 available on your newest i7. But ... in the browser! Fucking awesome I tell you.
  • Is this the whole HTML 2.0 thing where it's not HTML at all, but compiled code to "run faster"? If so, I want no part in this. The Web is perfectly speedy, but it's the Ads and garbage slowing it down. Combined with the MPAA and RIAA mafia's, ALL 4 major browsers simultaneously announcing support... and my conspiracy meter goes off.
    • by zlives ( 2009072 ) on Tuesday March 15, 2016 @02:29PM (#51701869)

      don't worry, it will never be used for DRM or adware

      • by Anonymous Coward

        ^^^ funniest joke all day! ^^^

    • This is Web 3.0. The search for more money.

      With ads running at assembly speeds they can play a dozen videos ads per page at the same time.

    • by firewrought ( 36952 ) on Tuesday March 15, 2016 @02:46PM (#51702009)

      It's a replacement of two previous ideas... Mozilla's asm.js ("let's specify a subset of JavaScript that can run faster") and Google's NaCL ("let's ship x86 code directly to the browser"). As best I can tell, the replacement resembles putting a Java/.NET-style virtual machine into the browser to execute a new form of bytecode (.wasm files).

      This is good for speed, which is in turn good for developers who want to deliver complex ("Photoshop-like") apps from the cloud.

      It's bad for security (expanded attack surface), and it's bad for privacy (more ways to fingerprint the browser).

      It's a wash for transparency: today's minified JavaScript is pretty much unreadable anyways.

      Probably my biggest concern off the bat is wondering how the ecosystem for web API's is going to work when everyone's developing in their own favorite programming language. Traditionally, JavaScript has been a uniting force in this regard.

      • The important thing to realize is that this isn't a new VM, nor a new set of APIs. Just like asm.js, it's still JavaScript, executed inside the same JavaScript VM as the browser already uses. WebAssembly is about delivering that JavaScript in an optimized format: binary instead of text (for smaller downloads and improved parse speed), and enforcing a JavaScript profile that enables improved JIT'ing (like asm.js).

        As such, the attack surface is the same. There is no new way to fingerprint the browser either

    • Don't forget that Javascript is slowing it all down too. Content loads fast, but the web-as-an-application-framework is what's wrong with the web. This is essentially Java applets reinvented but with the wrong lessons learned.

  • Ugh. Performance hacks.

    I understand that a lot of people want to be on the cutting edge all the time, but aren't all those people already pretty firmly in the native code camp? This seems like a compromise solution that will satisfy no one. Speaking for myself, in general I prefer to just wait for the computers to get fast enough to run the inefficient-but-maintainable code over dealing with some uber-optimized smegma.

    • Why do people want to stick everything in a web browser? It's like they want us to have only one tool (the browser), to rule them all ...
      • by ranton ( 36917 )

        Why do people want to stick everything in a web browser? It's like they want us to have only one tool (the browser), to rule them all ...

        Many people would like an ecosystem similar to when all computers had Windows and Internet Explorer, where you only had to worry about writing for a single platform. Many changes to web standards are an attempt to get the benefits of a single platform to target but without a single corporation owning that platform. Time will tell how it works out.

        • The consumers aren't asking for this. They're quite happy using different environments, even ones that don't share the same software pool. Apple vs Windows is a good example of that. For everything else, there's java.
          • I'd disagree, for the most part-

            * Consumers are asking for something like this. Not everywhere, and often because they know it's generally not up to them, but platform lock-in is a pain for many people. "I have to buy a PS4 for this game." "This product isn't going to support Mac." "Only on iOS." "Requires Flash."

            * Devs are definitely asking for something like this. "Can we afford to port to platform X? Can we afford not to?"

            How things are now, we're talking about a lowest-common-denominator problem, so onl

            • Someone who has to buy a PS4 because the game won't play on a PS2 or PS3 is in the same situation. Big deal. You can't achieve the same performance from one-size-fits-all code, so gaming is going to continue to require code adapted to each platform.

              Most devs are smart enough to understand that one-size-fits-all means going with the lowest common denominator for functionality. And let's ber honest - web platforms are the sh*t. They always have been. They always will be. Just one more layer to be compromised

      • It's the one platform that's OS-independant, at least in theory.

        It gives me hope that all four major browsers are in this together but at the same time it's going to give me nightmares about what the advertising companies are going to do with it.

        I hope nobody messes up the sandboxing of this whole thing.

        • Java is os-independant, and actually has fewer security flaws than web browsers. Solved problem, but people are too lazy to learn "real programming", even simplified as much as Java is. Web script monkeys are their desire.
          • If Java was really OS-independant, Minecraft would be able to run on all operating systems. But it's Windows-only, so there you go.

            • I can write java code that will run on *nix and not Windows - doesn't prove that it is os-independent, just that you can get around that feature, so as you said. there you go.
          • by dave420 ( 699308 )

            Your prejudice is worrying.

            • Not to moi :-) In case you haven't noticed, there's been a huge push to make programming a low-cost commodity. That's possible with simple scripting languages, not so much with C, etc.
      • Single point of failure is easier for the casual users.

        • Strange how that hasn't worked out too well ... and mathematically it's the inferior approach. Not to mention that a single point of failure hoses everything.
    • Javascript as maintainable? :-) Native code folks have a big lead on tooling that JS is slowing getting. But I also believe it comes down to language support. There are so many things about JS that I don't like that I can't believe people are building great stacks on top of it. Sure JS has plenty of happy features (like closures) - but I think it is growing old quickly. What people want to use it for is causing stress marks to appear.

      Lint is still weak. People are still writing unit tests just to ve

    • by non0score ( 890022 ) on Wednesday March 16, 2016 @02:06AM (#51705989)

      That's a pretty naive interpretation of Webassembly. Let's address your comments.

      1) Yes, the target audience are in the native code camp. But outside of mobile, there is no good delivery mechanism, other than the web. This is basically doing that: brining the web to native apps.
      2) There is no cross platform sandbox for running native apps, and this delivers on that. All modern browsers at least attempt at security, whereas non mobile platforms offer very little in terms of security against native apps.
      3) Computers aren't getting "fast enough" (or much faster, for that matter). Especially not for mobile, which will always be slow because of power requirements. This spec will greatly help with that.

      So it serves many purposes, and I think is a wonderful boon to the web.

  • by vivaoporto ( 1064484 ) on Tuesday March 15, 2016 @01:50PM (#51701549)
    This development can very much be a big reason of concern. Setting aside the fact that this will bring closed source software to an arena where it is mostly non-existent (the scriptable part of the web) this will also open a new vector for malicious scripts to hide.

    If it is already a vector today imagine when it is a binary that you cannot even cursorily inspect before running.
    • by Junta ( 36770 )

      Look at most sites that deploy javascript nowadays. The variable names are mangled beyond recognition, all whitespace and comments have been removed. It's already as difficult as debugging assembly code, but with limited upside. In theory at least, embracing a reality of bytecode rather than making an interpreted language behave like bytecode can get some gains.

    • Webassembly runs inside the browser's sandbox, which is at least as good as running it natively on your OS in terms of security. That and NaCl/asm.js has been around already, so I'm not sure how this will be an issue.

  • Pretty darn sure they will work out a way slip in anti-ad blocking functionality.
  • I guess Mozilla just can't sit still until they have an OS behind their name that creates the buzz unlike FF OS and more like Android. But seriously, blocking a JVM plugin (instead of maybe working to fix it by submitting fixes to Oracle if that was necessary) but creating a completely new VM to run bytecode inside browser directly... I guess so that eventually they'll just supply the VM and the browser itself will be written as an add on to it in WebAssembly, so that eventually somebody could port the ori

    • by Anonymous Coward

      completely new VM to run bytecode inside browser

      It isn't a new VM. WebAssembly targets the existing JavaScript VM that's already there in your browser. You should do some reading [] on WebAssembly.

  • by Elledan ( 582730 ) on Tuesday March 15, 2016 @05:54PM (#51703755) Homepage
    Last December I took an extensive look at ASM.js and WebAssembly, from the point of view of an old-school C/C++ developer, and wrote an article about it: A look at asm.js and the future with WebAssembly [].

    The short of it is that while interesting, the JavaScript runtime both asm.js and WebAssembly run in impose such major limitations on the applications being written that its actual uses outside of game ports is fairly limited.
  • I thought it was just a joke []

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson