Slashdot Mirror
WebAssembly: An Attempt To Give the Web Its Own Bytecode
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
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).
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.
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.
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.