Slashdot Mirror

← Back to Stories (view on slashdot.org)

WebAssembly: An Attempt To Give the Web Its Own Bytecode

Posted by timothy on from the where-is-your-bottleneck dept.

New submitter Josiah Daniels writes with this kernel from a much more detailed article at Ars Technica about what already looks like a very important initiative: WebAssembly is a new project being worked on by people from Mozilla, Microsoft, Google, and Apple, to produce a bytecode for the Web. WebAssembly, or wasm for short, is intended to be a portable bytecode that will be efficient for browsers to download and load, providing a more efficient target for compilers than plain JavaScript or even asm.js

29 of 126 comments (clear)

  1. Guys, you're losing it by Anonymous Coward · · Score: 3, Insightful

    The web is hardly usable anymore. Even the simplest web sites are slow as molasses, thanks to heaps of "active" content alongside the actual information. Now you're going to bestow your own runtime on us? Now that we've finally ditched Java and Flash?

    1. Re:Guys, you're losing it by viperidaenz · · Score: 4, Informative

      You're confused about Java
      The byte code is compatible.
      Code compiled in the first ever Java compiler will run on the latest JVM. There have been a few additions to the byte codes, so it doesn't always work the other way.

      If you really want your new code to work in old JVM's all you need to do is set the compiler compliance level.

      You don't need to down-grade a JVM for it to correctly interpret byte code from an old compiler.

      The compatibility problems come with changes to the run-time libraries. Byte code has nothing to do with that. Compiling from source won't fix it.

    2. Re:Guys, you're losing it by Dutch+Gun · · Score: 2

      A bytecode format is easy to maintain backward compatibility with, and because it's bytecode, not native code, it's fairly easy to enforce proper sandboxing at a pretty low level. It could be argued that this is actually what JavaScript and the security disaster that is the Java plugin should have been from the beginning.

      Like with the .NET CLR (Common Language Runtime), you can actually use just about any language you want to that's designed to compile down to this common runtime (or in this case bytecode format). This means you aren't stuck with using only Javascript or a language that translates to Javascript. Hell, if Javascript can be compiled to this bytecode format, then web browsers can actually depreciate the JavaScript-specific runtimes in favor of a generic bytecode runtime (although that would be pretty distant).

      It's pretty easy to think of several advantages to a more generic bytecode versus a specific language. The obvious downside is another round of security issues with another way to run script code from a website on a person's local machine. No matter how carefully implemented this is, there *are* going to be new security issues found and exploited. The good news is that with a common bytecode format, you really only need to solve most of those issues *once*, and not for every new supported language or plugin.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    3. Re:Guys, you're losing it by swilly · · Score: 3, Informative

      This is mostly true, but it is worth expanding as there are a lot of misconceptions about this. Java bytecode contains the JVM version it was compiled against, and later JVMs will run it just fine, even if it will no longer compile. I remember when Java added the enum keyword, and all our applications ran fine on the new JVM, even though it wouldn't compile without changes (one of our programmers used enum as the standard variable name for Enumerators). Overall, I've been very impressed with Java's cross platform and version compatibility, but I have found three causes of compatibility problems that are worth knowing about.

      First, you cannot rely on non-standard libraries such as the com.sun packages. These aren't guaranteed to exist from one version of Java to the next. They aren't even guaranteed to work the same between minor Java versions. If you limit yourself to the standard libraries, you are safe. Be advised that deprecated methods may be removed in the future, though none have been removed so far.

      Second, some programmers explicitly version check the JVM. This is usually for compliance issues, as some organizations feel that code should never run against a JVM that it hasn't been formally verified against. I have also seen this done because code was written to a known bug and some idiot thought it would be better to ensure that the underlying JVM always had the bug rather than work with both bugged and unbugged JVMs. Whatever your reasons, I consider this to be a bad practice, as you won't get security fixes from updated JVMs.

      Third, while bytecode should always be forward compatible (barring bugs in the Java library), if you use native code you should be aware that JNI libraries are not guaranteed to work across major JVM versions. JNI libraries must be recompiled to work on newer JVMs.

      There may be other sources of compatibility problems, but these are the only that I've run across them in my 15 years maintaining several million lines of Java code.

    4. Re:Guys, you're losing it by swilly · · Score: 2

      You can get the version of the compiler used to compile a class file (which contains the bytecode) using "javap -verbose MyClass.class". A major and minor version will be at the top. For what it is worth, Java 7 uses major version 51.

    5. Re:Guys, you're losing it by jdschulteis · · Score: 2

      The web is hardly usable anymore. Even the simplest web sites are slow as molasses, thanks to heaps of "active" content alongside the actual information. Now you're going to bestow your own runtime on us? Now that we've finally ditched Java and Flash?

      JavaScript and the DOM is a runtime that has replaced Java applets (almost completely) and Flash (mostly). There's room for improvement in performance.The problem with asm.js is that it's a Mozilla thing, even though asm.js runs quite well on Chrome. The problem with Dart is that it's a Google thing, even though it can be transpiled to JavaScript.

      WebAssembly has all four of the key players involved (Mozilla, Google, Apple, Microsoft). Maybe, just maybe, we'll be able to write code in a language that suits the task and have it run fast in any browser. I'm crossing my fingers but definitely not holding my breath

  2. WTF with the new comment links? by Anonymous Coward · · Score: 2, Interesting

    Why did /. ruin their layout by moving comment counts into the headlines? Sometimes the counts do not display at all. Is Dice outsourcing design to Retardistan?

    1. Re:WTF with the new comment links? by Anonymous Coward · · Score: 2, Funny

      They can't even do Unicode or https correctly. You are expecting too much from the script kiddies that run this site.

  3. Completely unnecessary by fishscene · · Score: 2

    Not needed. Simple as that. Our devices are getting more powerful each generation, and they worked well enough with HTML and human-readable text. This probably wouldn't even be on the table if it weren't for the bazillion advertisements and spyware on most major websites. My 2 cents at least.

  4. Makes Perfect Sense by cmorriss · · Score: 4, Insightful

    This is ultimately where the browsers need to go. Many have tried in the past, but always from some side angle assuming that it had to be through a plugin or had to use Javascript as the underlying byte code, e.g. GWT. This could finally allow a wide array of languages to be used to build web applications, similar to the explosion of languages that now run on a JVM.

    --
    10 minutes working on a sig. What a waste.
    1. Re:Makes Perfect Sense by goruka · · Score: 2

      It will take a while to convince developers that running this kind of native code is not unsafe, and that this is technically different (and very superior) to NPAPI, ActiveX, Java, Flash or Silverlight in terms of portability and security.

    2. Re:Makes Perfect Sense by Anonymous Coward · · Score: 5, Interesting

      No. We need to completely abandon this aspect of the browser. Desktop applications are far, far better and their toolkits are far better. What we need is excellent sandboxes so you can download any program and run it without fear of destroying your system. Doing everything as web apps only makes the installation process easier. It makes everything else harder. Instead of trying to make everything else easier, we should be making the single task of installation easier and safer.

      Everything the web is doing already exists in 'real' applications, they're just reinventing everything badly in an attempt to get around HTML shortcomings. The easy solution is to drop back to real applications running with similar restrictions as web pages have. We used to have that but the sandboxes had too many holes. Please just make better sandboxes instead of turning everyone's browser into more of an OS.

  5. Back to the future .. by nickweller · · Score: 4, Insightful

    Java virtual machine (JVM)

  6. Re:Too slow by jbeaupre · · Score: 4, Funny

    If you'd submitted it in some sort of compressed, machine readable format, it would have been faster.

    --
    The world is made by those who show up for the job.
  7. The Web needs a lot of things by Livius · · Score: 3, Insightful

    I've been saying this for twenty years.

    Java tried to be this, and unfortunately came close enough to remove the incentive to improve but not quite good enough to really accomplish the goal.

    Everything on the web is ultimately a crude hack on top of HTML, which is why there are new development and deployment frameworks constantly being created, because no-one has come up with something good.

    1. Re:The Web needs a lot of things by quietwalker · · Score: 4, Informative

      I have also been saying this for years.

      It's nice that HTML and CSS were accessible to the masses, and without their simplicity, we could never have reached the level of adoption we now have. See the argument over the MEDIA vs. IMG tag from way back for a good example of that. However, now, that additive simplicity is holding us back.

      What we need is a language with flow control, variables, functions, templating, the whole 9 yards. Not just on top of HTML & CSS, but as part of it. So we can dynamically change the size of page elements based on other page elements (think layout managers) without making incredibly complex and highly specific css for a variety of media screen sizes. Common features like centering a dialog box or a three-column display with header and footer sections shouldn't be a hack you need to ferret out, that may behave badly with long or short pages. It'd be nice to explicitly link action management with page elements and avoid much of the code required to identify actors and route events. Heck, some sort of built in asynchronous request mechanism might be nice, rather than having to write custom javascript each time.

      What we don't need is another life support extension to a markup language.

    2. Re:The Web needs a lot of things by viperidaenz · · Score: 4, Insightful

      Have you tried the latest framework, Vanilla JS? It's faster and more efficient than any other framework.

  8. Here's a FAQ for slashdotters by goruka · · Score: 5, Informative

    1) Why is this needed?

    With the removal of binary plugins in Chrome and Edge (and soon to happen on Firefox), a way to code at native performance in the browser is still needed. Mainly to run high performance games, audio software, etc. You may not want it, but a lot of people consumes this content so there is a large industry behind it.

    2) Why not asm.js?

    This is almost the same as asm.js, except it's precompiled, so it' s more efficient for Javascript engines to JIT or AOT. Currently, compiling large asm.js codebases results in a large download and resource intensive compilation.

    3) How is this different from Java, Flash, Silverlight?

    It is different because:
    A) It' s a w3c standarized effort
    B) All the big players are behind it (Google, Mozilla, Microsoft and Apple)
    C) It relies on the browser security model, it does not bypass it
    D) It' s a low-level bytecode, more so than AS3, JVM or Silverlight, so it can run any language.
    E) It runs in the same "space" as the DOM, it's not a separate/embeeded app.

    4) Isn' t this unsafe or a new attack vector?

    No, it relies on the same browser security model as Javascript, so It's as dangerous as having Javascript enabled. Read up on how PNACL works for material on why this is not unsafe.

    5) Will it replace Javascript?

    It is not intended to, but it gives developers the same API with the ability of writing in any language, even C++, so developing a website using tools such as Qt will become possible (efficiently at least).

    1. Re:Here's a FAQ for slashdotters by NotInHere · · Score: 2

      A) It' s a w3c standarized effort

      Close, but still wrong

      We’re pretty early into the overall process—there is no draft spec or even final formal standards body chosen, just a W3C Community Group

      But it will be an open standard, thats sure.

    2. Re:Here's a FAQ for slashdotters by firewrought · · Score: 2

      4) Isn' t this unsafe or a new attack vector? No, it relies on the same browser security model as Javascript, so It's as dangerous as having Javascript enabled. Read up on how PNACL works for material on why this is not unsafe.

      Except you're bypassing the compiler now and potentially accessing a larger portion of the sandbox attack surface than before.

      --
      -1, Too Many Layers Of Abstraction
    3. Re:Here's a FAQ for slashdotters by peppepz · · Score: 2
      Point A: Java was standardized by a consortium as well. I believe that even the APPLET tag was standardized by the w3c. Oh, and that was before the w3c had began “standardizing” DRM hooks.
      Point B: When Java was added to HTML, everyone and his dog (including Microsoft) thought that Java was the future and that every software in the world would have been rewritten in Java. Proof in the fact that the "Java" branding was added to Javascript in order to increase its appeal.
      Point C: the sandbox for Java applets gave the unsigned ones even fewer permissions than the current Javascript sandbox does for the most obscure of the web pages.
      Point D: Compilers have been written targeting the JVM bytecode for pretty much every modern language (Python, Ruby, Scala, Lisp and, of course, Javascript), many of them actually faster than their reference C implementations, so I don't know how much lower in level you can get.
      Point E: Look, DOM manipulation from an applet. And do you know what else integrated even more with the DOM? Microsoft's ActiveX.

      But above all, all points, even if they were true, are but minor differences in implementation, compared to the huge fact being the very nature of a bytecode that is supposed to be run by web pages, that alters the open nature of the web by making its pages write-only, and the introduction of a compiler into the workflow of HTML development. (Who will make the better compiler, Microsoft or Mozilla? Will php scripts output bytecode or do we have to change server-side scripting? What's the failure model for browsers implementing an older subset of the bytecodes?)

  9. Yea something other than JS by MightyDrunken · · Score: 2

    I like many other people are forced to work in JavaScript. It's not too bad a language if you are careful but it would be nice to have some choose when working with webpages.While at first it will be all JS they plan to expand WebAssembly to other languages which could be compiled to the bytecode. Hurrah!

    --
    The most dangerous drug
  10. Evolution of PNaCL, asm.js by Guspaz · · Score: 2

    This is literally various similar projects (PNaCL, asm.js, etc) being merged into one industry-wide project. And by literally I mean the PNaCL and asm.js teams are working on WebAssembly.

    1. Re:Evolution of PNaCL, asm.js by Goaway · · Score: 2

      Everybody do most definitely not know that PNaCl is the way to go. PNaCl suffers from many difficult problems, such as being based on LLVM bitcode, which is not static, but is machine-specific and has undefined behaviour. The PNaCl team has put a huge amount of effort into working around those fundamental problems, with quite a bit of success, but it's still not in any way a very good solution.

      wasm will take advantage of some of that work, it seems, but its bytecode will be more strictly defined and designed for the purpose, which will help a lot. wasm is much more based on asm.js, being at first just a binary encoding of it. That in itself is a huge improvement on the hacky way it was originally implemented, though.

  11. Why not improve Java? by drolli · · Score: 3

    Probably some legal bullshit, but I think the effort could be better spent in making the JVM attractive and safe for the web...

    1. Re:Why not improve Java? by non0score · · Score: 2

      No thanks. Why jump through hoops for direct memory access on a JVM when one can just embed the JVM on top of WebAssembly?

  12. Re:So, I had a thought about this a while back by TechyImmigrant · · Score: 2

    It boils down to "why not pre-compile entire websites into binary packages per-page? It would make it much faster and more efficient for the browser to load it..."

    http://developers.slashdot.org...

    Or we could write programs, compile them and let users run them on their computer.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  13. Re:Great, another attack vector by Goaway · · Score: 2

    asm.js already exists, and already runs in your browser, and is not the cause of any known security issues. This is just a different packaging for the exact same thing.

  14. A solution in search of a problem by Millennium · · Score: 2

    "Efficient downloading" is a nonissue. Existing compression, concatenation, and minification techniques yield file sizes that a binary format will have a great deal of trouble beating at all, and even when it does, the savings will be no more than a few bytes at best.

    "Efficient parsing" is a nonissue. This has been true for decades. Browsers simply do not spend enough time parsing JavaScript for it to ever become an issue. This is sorely misguided premature optimization at best.

    "Language choice" is a nonissue. Emscripten and its kin have already solved the problem of compiling other languages to JavaScript. These languages will still have to be compiled to the bytecode, and gain no benefit from doing so.

    "High performance" is a nonissue. This is what asm.js is for, and indeed, the existing polyfill uses asm.js to achieve its performance gains. This is a newer solution than those for the previous problems, but either way, the problem is solved.

    "A standard runtime specification" is a nonissue. We already have one of those. It's called ECMAScript.

    There is no point to this. All it does is comply with buzzwords and kowtow to JavaScript-haters. And make closed-source Web applications that much closer to feasible, I guess, but no one would consider that a benefit, right?