Become a fan of Slashdot on Facebook


Forgot your password?

WebAssembly and the Future of JavaScript 175

Nerval's Lobster writes: WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript's speed. That's not to say that JavaScript is a slowpoke: Incremental speed improvements have included the rollout of asm.js (an optimized subset) in 2013. But WebAssembly—while not a replacement for JavaScript—is intended as a "cure" for a variety of issues where JavaScript isn't always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here's a full list of the Web applications that WebAssembly could maybe improve.) If WebAssembly is not there to replace JavaScript but to complement it, the key to the integration rests with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. The bigger question is, will WebAssembly actually become something big, or is it ultimately doomed to suffer the fate of other hyped JavaScript-related platforms such as Dart (a Google-only venture), which attracted buzz ahead of a Minimum Viable Product release, only to quickly fade away afterward?
This discussion has been archived. No new comments can be posted.

WebAssembly and the Future of JavaScript

Comments Filter:
  • WebAssembly (Score:2, Insightful)

    by Anonymous Coward

    Never heard of it. Probably a passing fade. I predict decades more of Javascript and (alas) Flash.

    • Decades more of Flash, eh? Is that the same Flash that I haven't used in over three years now?

      • Re:WebAssembly (Score:5, Insightful)

        by narcc ( 412956 ) on Wednesday July 08, 2015 @11:25PM (#50073611) Journal

        Here's something you might not know: Your personal use case is not representative of the world at large.

        Flash is still quite popular, and isn't likely to vanish any time soon. Millions upon millions of users engage with flash content on the web daily. It's going to take a very long time for alternatives to catch-up in terms of authoring tools and, most importantly, content. It'll take even longer for that old content to fade into obscurity -- just like Java applets before it.

        I know it's cool to play the ideologue, but it's foolish to deny the obvious reality. Flash is going to be with us for many years.

        • by j127 ( 3658485 )
          Flash doesn't run on iOS, so it's already on the way out. I block Flash on most websites, and rarely need to enable it. Flash will be around for many years but it's already on a major decline.
          • Re: (Score:2, Informative)

            by Anonymous Coward

            iOS actually sees relatively little use. Yes, selling a comparatively small number of rather expensive phones and tablets does give Apple some impressive revenue numbers, but the proportion of iOS users is very small. There are many more users using cheaper Android devices from a wide variety of manufacturers.

            Look at these recent browser usage stats [], for example. iOS Safari is only about 7%. The old Android browser is still at over 5%, plus there's Chrome for Android at over 13%, and UC Browser for Android

          • Re:WebAssembly (Score:4, Informative)

            by narcc ( 412956 ) on Thursday July 09, 2015 @01:17AM (#50073907) Journal

            Flash doesn't run on iOS, so it's already on the way out.

            So said everyone ... 7 years ago. At this point, it's just pure delusion. iOS just isn't relevant.

            The "major decline" you and everyone else has been on about nearly a decade just hasn't happened. Flash has declined, sure, but not significantly. Google and Mozilla recognize this, and have taken steps to ensure flash content will work in their browsers for the foreseeable future. After all, if their browser can't render the content people want, they'll look elsewhere.

            I suspect we'll have this exact same discussion 5 years from now. There's just too much content and the alternatives just aren't mature enough to see any significant change over the next few years.

            This is simply reality.

            • The "major decline" you and everyone else has been on about nearly a decade just hasn't happened. Flash has declined, sure, but not significantly. Google and Mozilla recognize this, and have taken steps to ensure flash content will work in their browsers for the foreseeable future. After all, if their browser can't render the content people want, they'll look elsewhere.

              One would think that they could just eventually turn it into an HTML5 library...

            • indeed. All that's really happened is that Apple fans have missed out on Flash's 'killer app': []

            • Mobile browser statistics [] suggest otherwise, but OK let's join you in fantasy land where "iOS just isn't relevant" to the web.

              How about Adobe? Is Adobe relevant to Flash? Because it was Adobe who pulled the plug on Flash mobile in 2011 []. Flash on mobile is a bloated battery-draining joke. Apple merely recognized that fact first.

              And if you're suggesting that mobile web is less relevant than desktop web, you've gone full retard [].

              The decline HAS happened, and is still happening [] (are you saying a decline from

        • [...]Flash is going to be with us for many years.

          Like herpes. Except that HTML5 can, and does cure it.

    • Re:WebAssembly (Score:4, Informative)

      by TheRaven64 ( 641858 ) on Thursday July 09, 2015 @04:29AM (#50074307) Journal
      Why would you have heard of it? I've heard of it as a compiler writer, because the WebAssembly back end is currently being merged into LLVM, which will make it possible for all languages that LLVM can target to emit WebAssembly. It's basically the successor to PNaCl (heard of that?), but this time with cross-industry backing. Backers include Google, Microsoft, Mozilla, and Apple - that gives it a pretty good chance of appearing in all of the major browsers.
      • How well does WebAssembly compare to PNaCl? I was thinking or trying to do a "MetaOberon" (Oberon+OMeta) compiler, and am in search of a reasonable backend.
        • by robi5 ( 1261542 )

          There were a few mentions of (P)NaCl in this interview: []

          tl;dr Brendan Eich suggests (P)NaCl becomes irrelevant over time (or it has already) and WebAssembly is the future.

        • It's very similar. WebAssembly is less closely tied to LLVM in its IR (which is a good thing, as LLVM IR changes over time quite significantly and maintaining compatibility with something that's almost LLVM IR is quite hard). Many of the people who worked on WebAssembly also worked on PNaCl, so have had the opportunity to learn from their mistakes and not have to worry about backwards compatibility.
  • by creimer ( 824291 ) on Wednesday July 08, 2015 @06:25PM (#50072439) Homepage
    I can learn assembly language! On the web, no less!
    • by Anonymous Coward

      Real programmers use WebMachineCode.

    • by markus ( 2264 ) on Wednesday July 08, 2015 @06:44PM (#50072545) Homepage

      You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.

      But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.

      The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.

      This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.

      • by cb88 ( 1410145 ) on Wednesday July 08, 2015 @10:30PM (#50073433)
        Javascript doesn't have robust anything....
        • You know, I really don't recall the last time a JS program jumped back at me with a memory bug.
        • by robi5 ( 1261542 )

          It has robust performance for a scripting language, running circles around Python, R (not including NumPy / BLAS / ATLAS), Ruby etc. dynamic languages; faster than most JVM based (non-Java) language implementations, and - for example, from my profiling on number crunching tasks - around as fast as Java.

          Also, there are not a lot of recent reports that start with: 'Due to a vulnerability found in JavaScript, millions of credit card details were exposed'

      • by AmiMoJo ( 196126 )

        You can write WebAssembly by hand, in the same way you can write Java bytecode by hand. You probably wouldn't want to though.

        Although C++ is supported, not all of it is. The environment is heavily sandboxed too. Porting existing C++ will need some work, it's not just a recompile, although I think you realize that.

    • by PPH ( 736903 ) on Wednesday July 08, 2015 @07:25PM (#50072731)
      There's a book [] out already.
  • by msobkow ( 48369 ) on Wednesday July 08, 2015 @06:32PM (#50072487) Homepage Journal

    One of the big "security benefits" I've heard claimed is that WebAssembly will only be able to invoke the same functions/methods as JavaScript itself. So that implies that WebAssembly is nothing more than pre-compiled JavaScript.

    As the compile phase of JavaScript pales in comparison to the execution phase, the only people I can see pushing for this are those who want DRM-style protection of their JavaScript so no one else can read it.

    • by markus ( 2264 ) on Wednesday July 08, 2015 @06:50PM (#50072591) Homepage

      An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.

    • Javascript has features that make it difficult to optimize and compile (like the ability to create new functions from code at runtime, or the fact that every variable is an associative array).
      WebAssembly is a reduced-functionality version of Javascript that allows better optimization. That is the purpose.
      • V8 actually has two JIT compillation modes exactly because of things like this. One handles "easy" functions and the other handles "hard" functions (functions that contain eval or try and catch for example), the "easy" compiller has worse performance. This link explains it well: []

        Great read for people who want to optimize for V8, many of the tips should be valid for other javascript engines as well.

        From the article:

        Currently not optimizable (ie will use the slower compilation

        • by robi5 ( 1261542 )

          Yes, it's interesting how often the newly introduced ES6 etc. elements are slower than what they replace, even though the ES6 version is typically saner and more conducive to optimization. For example, Maps are probably still slower than the current string based objects. But we don't have to go that far. A couple of years ago there were bug reports about the performance of typed arrays. The very point of typed arrays is that they can be made faster (and of course WebGL support through number type representa

          • Yeah it is because the optimizing compiler does not know how to optimize those things yet. But in reality having a proper examinable bytecode would be better for those times you actually need every little bit of performance. Examining the bytecode of your own code is easier than trying to understand the compiler (badly documented and forever evolving) optimizations.

    • WebAssembly (WASM) is, at least initially, just a ASM.js with better compression (binary). You can even convert losslessly between ASM.js and WASM. And do remember that ASM.js is just a subset of JavaScript that removes slow features, so you can convert all the way back to plain JavaScript from WASM. ASM
      Js proved that JavaScript subsets could be almost as fast as native, and that killed any justification for Googles Native client (Nacl/pnacl) which if popularized would have added 8mb of undefined behavior t

    • by j127 ( 3658485 )
      I don't like the idea of precompiled JavaScript, because it will be harder to block trackers and advertising.
    • It's more than just pre-compiled Javascript. It has proper types (like integers! In 2015!), unlike Javascript. It will be an easier compilation target than asm.js for both traditionally compiled languages (C/C++) and newer languages. There will be freedom to break from Javascript conventions that have held back the Web, such as the single-threaded nature of the Javascript VM (of course there are Web Workers, but no proper shared memory model currently etc. -- this slows down multithreaded code, requires a d
  • Google and MS are teaming up on this and it will be in AngularJS 2. With that kind of weight behind it, I'd bank on it being the next JS replacement/supplement.
  • by markus ( 2264 ) on Wednesday July 08, 2015 @06:38PM (#50072513) Homepage

    Previous attempts at replacing JavaScript always suffered from a boot strapping problem. While there are only a small number of major desktop browsers, overall, there are actually a lot of different minor browsers that people expect to work. And even among the desktop browsers, not everybody always runs the most recent release.

    Content producers don't really like writing content that only 30% of their users can view. So, unless a new technology is rolled out to 90+% of the deployed browsers, nobody is going to write content for it. On the other hand, if nobody writes content, the rest of the browser manufacturers won't put any resources into adding support for the new technology.

    Both asm.js and WebAssembly have a fallback mode that uses plain JavaScript, as available in virtually 100% of all browsers. Performance will obviously be degraded, but that's much better than making the content completely inaccessible. And users are more likely to upgrade their browsers, if they can see a low-fidelity version of the content and know by switching to a newer browser they'll get the high-fidelity version. So, unlike the previous scenario, this is actually a virtuous circle.

    • Content producers don't really like writing content that only 30% of their users can view.

      Developers of exclusive apps for Mac, iOS, and video game consoles have historically not had much of a problem with limiting their market. They think they can get a better overall return on investment from targeting OS X only compared to OS X and Windows, or iOS only compared to iOS, Android, and Windows Phone, or one console compared to all consoles plus Windows PC.

      • by markus ( 2264 )

        A application that only sells in the Apple store is very different from a web site that can only be viewed with an iPhone.

        • by tepples ( 727027 )

          Trying to avoid DWAD []:

          A application that only sells in the Apple store is very different from a web site that can only be viewed with an iPhone.

          In what way, other than that one is wrapped in a UIWebView and one isn't? I'm curious as to your reasoning.

          • by Fwipp ( 1473271 )

            There's no expectation that an Apple Store app is going to work on Android, or a windows laptop, or a PS3. When I look for Android apps, I check an android app store - I know that the vast majority of what I find will work on my device.

            But everyone who visits a website expects that website to render and work for them - there's no segregation between "the apple web" and "the microsoft web" when you're at your computer, it's all just one big pile of sites. Users are aware that sometimes there are browser-spec

          • by AuMatar ( 183847 )

            Non-iphone users would try to use your website and be unable to. This will make your software look crappy, which will cause bad reviews and diminished PR. Look at games- you can develop for just PS4, and that's fine because a PC user isn't going to even try to use it. Release an unusable PC port like the latest Batman game, and you get complaints, bad reviews, and lost sales because everyone's heard how crappy the game is.

            • by tepples ( 727027 )

              Non-iphone users would try to use your website and be unable to.

              I already get that, with sites such as Instagram and Vine requiring download of a phone app just to set up a commenting account.

            • > Non-iphone users would try to use your website and be unable to. This will make your software look crappy.

              BS. You can traverse any number of urls in your favorite browser that are not supposed to open for you, ever, because they are API endpoints, behind authentication wall, or any other reason. Nobody prevents me from deploying a customized http://thenewestiphonesonlytha... [] and just plain redirecting anyone and everyone whose user agent looks even slightly off. And if you got there by changing your us

  • by wrmrxxx ( 696969 ) on Wednesday July 08, 2015 @06:42PM (#50072535)
    JavaScript execution speed is not the important thing about WebAssembly. What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages, almost all of which are likely to be better than JavaScript in one way or another.
    • What does matter is that it may open up the development of software for execution inside a browser to a wider variety of languages

      That already existed: Emscripten compiles any language with an LLVM front-end, such as Clang++, to asm.js. Apparently one of the goals of WebAssembly is to make Emscripten more practical.

      • by markus ( 2264 )

        Exactly. Think of asm.js as the proof-of-concept and WebAssembly as the production-ready solution.

        asm.js was a very valuable first step to get the browser vendors on board. But WebAssembly will push much further. Most importantly, it intends to support POSIX threads for languages such as C++. That's something that asm.js never knew how to address.

        • I proclaim Larry's Law:

          Those who fail to understand Java will attempt to reinvent it. Poorly. And compile it to JavaScript.

          • by Jeremi ( 14640 )

            Those who fail to understand Java will attempt to reinvent it. Poorly. And compile it to JavaScript.

            Given the current state of Java-inside-the-web-browser, I don't see how they could do any worse than Sun/Oracle did...

            • Well you see, if you broke the rules and read the article, they're defining a new intermediate code format that's kind of like Java byte code (not really, but the intent is somewhat similar).

              This "WebAssembly" is an abstraction over real hardware, that is compiled just in time so it can be executed on the native hardware or converted to JavaScript and interpreted by a VM.

              Personally, I think it's cool but it's definitely reinventing a lot of concepts Java tried, succeeded at (cross platformness) and hilariou

    • by markus ( 2264 ) on Wednesday July 08, 2015 @06:48PM (#50072579) Homepage

      JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.

      But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.

      Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.

      • by weilawei ( 897823 ) on Wednesday July 08, 2015 @06:53PM (#50072609) Homepage

        JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.

        Bandwagon appeal. With your UID, you ought to know better. Provide a technical argument and/or step away from the keyboard until you've thought it over. Note that I'm not saying there isn't a good reason--only that your given argument is crap.

        • Provide a technical argument

          object notation, lambda, c syntax.
          Read JavaScript: The Good Parts by Douglas Crockford.
          Actually pretty impressive for javascript to become leading web scripting language.

          • by MobyDisk ( 75490 )

            I think weilawei really meant to say: "Provide a technical argument for why Node.js is gaining so much popularity." I am not sure if your post does that.

            The features you listed are in pretty much every other major language. The book you referenced is a somewhat tongue-in-cheek look at how to use the good parts of a bad language. The conclusion I reach from those points is "yeah, it's bad, but see how people took the good parts and made it useful." Which doesn't really support the argument for why it is

          • > Actually pretty impressive for javascript to become leading web scripting language.

            WTF? It's the only game in town. What language did you expect to become successful? Any other language requires a plug-in which makes it not universal - so therefore we all just stick with what's going to run across all the browsers - even though it's a shitty language.

  • We'll use it when it has 95% browser support. And no, polyfill doesn't count.

  • by tiagosousa ( 1931172 ) on Wednesday July 08, 2015 @06:58PM (#50072637) Homepage
    Might as well read an interview with the man behind webassembly []. Found it extremely informative and I'm looking forward to a future where all major browsers support first-class alternatives to javascript through webassembly.
  • It's time to rework the web presentation and GUI (non) standards. There are too many layers in the current stack, and it relies on fat clients where large GUI libraries and GUI-related code have to be potentially downloaded for every site. It's very poor factoring of tools, libraries, and bandwidth. The bulk of GUI libraries should be part of the browser.

    I suggest we start over with 2 new standards: one for a practical work-oriented CRUD & down-to-business browser (or browser mode); and one "eye-candy"

    • by Shados ( 741919 )

      That can't work for a simple reason. Half of the people working on all these standards are downright retarded, and only failure in the real world gets them to realize it. Google's and Microsoft's representatives are the worse offenders, trying to stick their obsolete development practices in the browser, and failing over and over and over. (Hell, THIS is yet another attempt by them along with Mozilla)

      They'll be the first ones trying to manipulate any kind of new standard, and what you'll get will be a weird

    • The direction things are moving is this:
      * The browser provides basic building-blocks (for display, execution).
      * Vendors supply programmer-friendly frameworks on top.

      For example, HTML5 allows you to create custom tags, which frameworks like angular.js makes plentiful use of. In fact, some people who use Angular.js don't even know how to write plain old html/javascript. Sad but true.

      If WebAssembly succeeds, it will do the same thing to javascript. JS will be gone, and you can use whatever language you w
      • by Tablizer ( 95088 )

        Vendors supply programmer-friendly frameworks on top.

        Yes, but it usually becomes a revolving fan-boy circus with rapid generations and new frameworks-of-the-week. Plus, cross-browser/version compatibility is still tricky. If you have public-facing sites, you need to support old browsers.

        We need the equivalent of a GUI-Oriented Netscape to come along and shake things up. Being a "product" tends to lock things down for long enough for a standard to catch on. JS/Dom Frameworks are too malleable to establish a

        • Yes, but it usually becomes a revolving fan-boy circus with rapid generations and new frameworks-of-the-week.

          That's how it is now. And it will only get worse for a long time into the future.

          Or better. I like having lots of frameworks, even if most of them (all of them?) are lousy.

  • Minor apologies for being a bit pedantic, but just in case anyone's confused by the possible misuse of the term "closure" in the summary...

    From the Wikipedia entry on closures []:

    The term closure is often mistakenly used to mean anonymous function []. This is probably because many programmers learn about both concepts at the same time, in the form of small helper functions that are anonymous closures. An anonymous function is a function literal [] without a name, while a closure is an instance of a function, a value []

    • by robi5 ( 1261542 )

      Why would an anonymous function need to be a function literal? What if it's the result of a compose, or some other higher level function?

      • by __roo ( 86767 )

        Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.

        So higher level function would return a closure value, which would be the function bound to the values in scope. Those a

        • by robi5 ( 1261542 )

          Thank you for the explanation, as an FP user I didn't have an issue with the concept of anonymous function vs. closure, so let's forget about closures - e.g. assume that there is no variable capture and all functions are pure - and let's stick to the meaning of anonymous functions as defined by the cited wiki page.

          If I have functions f and g, and have a higher order function C, which, for example, composes two functions, then C(f, g) is a definitely a function. Also, it is a function that has no programmer

          • by __roo ( 86767 )

            You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s. :)

            My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulat

  • by Anonymous Coward
    > Better execution for languages and toolkits that are currently cross-compiled to the Web (C/C++, GWT, ).

    Why? Widgets are the one thing that Javascript does right? And I doubt you will see a difference in performance as its sync access to the framebuffer that usually slows down 2D graphics drawing on modern hardware.

    > Image / video editing.

    Why would I do this in a web app? And the issue with doing this in a web app has to do with taking better advantage of the UI interaction model (using tou

  • Gary Bernhardt was ahead of the curve with his extremely amusing talk The Birth & Death of JavaScript.
    https://www.destroyallsoftware... []

    A look back from the year 2035, he talks about the importance of having a assembly language for the web (asm.js) and tongue and cheek allowed the world to move past JavaScript where it finally becomes both a dead language and also what everything is built on.

  • by Qbertino ( 265505 ) <> on Thursday July 09, 2015 @06:21AM (#50074537)

    Find a feasible FOSS replacement for Flash that enables fast and easy cross-plattform development for performant non-trivial 'good-looking' client applications - and you have a winner. Offer some tacky half-assed JS cross-compiler nonsense, and your new tech won't get off the ground. The Web and DOM tech is a mess enough as it is, without yet another PL/runtime solution thrown into the mix.

    However, I remain slightly optimistic that this may be the long awaited not-fucked-up-by-adobe FOSS Flash successor we've been waiting for. All other non-foss contenders failed throughout the last 15 years, but this might have a chance, also since there is nothing else around and the web has taken over as platform of choice due to 80ies style tech fragmentation via the mobile revolution.

    Two cents from a senior webdev.

  • To summarize the linked page...

    Intended Use Cases:

    • Programming

    Really, the only type of programming not listed there is hard real-time. Way to narrow your focus, guys.

If you had better tools, you could more effectively demonstrate your total incompetence.