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

Comments

Too slow

[NotInHere]

my submission here

Re:Too slow

[jbeaupre]

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

The 1990s called

[davidwr]

They want their bytecode back.

Re:The 1990s called

[Anonymous Coward]

Yeah, my thoughts exactly. "Holy crap! Apple, Microsoft, and Google just rediscovered Java!"

Re:The 1990s called

[thogard]

You mean 1970s?

The more the web evolves, the more it looks like TeX and DVI and Metafont but with video.

Guys, you're losing it

[Anonymous Coward]

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?

Re:Guys, you're losing it

[mlts]

Of course, there are the security aspects as well. We already have been down this road with Java (which did have a lot of promise, especially with HotJava as an example of a browser written in the language, and prototype CPUs that could execute Java bytecode natively.) However, it fell apart, and now, code running on the same JVM on a Mac may just completely fail on Windows, and the other way around. Then, there is finding the right JVM.

Of course, there will be updates. A bytecode language is never finished. So, Web bytecode 7.0 either has to be compatible with every release before that, or break programs. Similar thing happened with Java, which makes it a pain sometimes when using a browser to access some hardware that used an embedded browser/Java interface, especially with the security issues of backlevel versions.

Finally, a security model needs to be put into place, or this will make an excellent tool for bad guys to inject code into the browser and compromise it without a trace (barring memory snapshots by the hypervisor.)

Just say "no".

Re:Guys, you're losing it

[viperidaenz]

Somehow you're under the impression that JavaScript doesn't already run in its own virtual machine and simplifying the compilation process that already happens would somehow make things slower.

Re:Guys, you're losing it

[viperidaenz]

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.

Re:Guys, you're losing it

[Anonymous Coward]

The difference between Javascript and bytecode is the same as the difference between text protocols and binary protocols, so I guess that after HTML/2.0, an attempt to replace Javascript with bytecode was inevitable. Of course Javascript has it's own runtime environment with dynamic compilation, etc., but the added emphasis on running code created by a switch to bytecode is disturbing. Remote code execution by design. I already mentioned what I think of the pervasive use of Javascript on today's web. And they won't stop at changing the language: APIs will change to provide more low level access to the computer as well. In the end you'll wonder why you don't just download the EXE. It would certainly not be less secure.

Re:Guys, you're losing it

[Anonymous Coward]

That has nothing to do with anything.

Crappy websites are slow because they use bullshit like jQuery and 10 other libraries and don't take the time to remove stuff they don't need.
They have 50 different kinds of scripts all loading their own instances after pages load.
They have scripts doing constant DOM updates instead of doing it all in memory, then writing to DOM once.
They have timers running at zero speed, aka, as fast as the browser is allocating timeslices to the page, making the page lag like dicks.
ENCLOSURES, ENCLOSURES EVERYWHERE. WE HAVE TO GO DEEPER. Every layer of enclosure adds considerable slowdown. (that is admittedly a JavaScript problem that I hope gets rewritten some time. Fuck that scopechain noise.)

Don't blame crappy website developers for abusing JavaScript.
You can abuse pure HTML just as easily.
Even Flash can have very good code written for it. Hell, it had Unreal Engine running in it and it ran better than all Source games. (not that that is a hard task)
I remember seeing a Flash forum, a pure flash forum, that ran better than most forums I have ever used since the mid-90s.

The ease of entry to webdev is why websites are terrible, not the technology behind it.
Most crappy developers that make those websites is like someone making a car out of whole chairs.
Yes. That is a perfect example of a crap webdev, a car made of chairs. Everything is chairs. STOP MAKING CARS OUT OF CHAIRS.

Also, JavaScript is already a VM. It has been a VM for several years now.
It is probably one of the few good things Google has done in the past 10 years.
Along with most of the HTML5 spec, fixing all the old specs, and preventing that atrocious XHTML2 from going anywhere. (What a terrible idea, go away XML people, it will never happen, HTML is superior.)
Other than that, they are terrible now.

Re:Guys, you're losing it

[Anonymous Coward]

That has nothing to do with anything.

It has everything to do with that. People are wrong if they see the web as something that should involve executing code that is included with a web page, and offering more ("better") tools to do just that will lead more people to think about the web as a programming platform.

Crappy websites are slow because they use bullshit like jQuery and 10 other libraries and don't take the time to remove stuff they don't need.

First of all, it's not just "crappy" websites that do this, it's almost all websites. And with bytecode, it will get much worse, because those library monkeys are going to feel like they can do so much more now that they're no longer shackled by Javascript.

They have 50 different kinds of scripts all loading their own instances after pages load.

Now it's 50, then it will be a hundred or more, because it's "fast". Also, DLL hell will look positively cozy when the web is one giant distributed program.

They have scripts doing constant DOM updates instead of doing it all in memory, then writing to DOM once.

Remember Flash websites? Welcome to "canvas" websites. Who needs DOM when you can run bytecode fast enough to paint your own GUI in a full page canvas element?

They have timers running at zero speed, aka, as fast as the browser is allocating timeslices to the page, making the page lag like dicks.

And they need faster code execution to do more of that.

They'll tack on all sorts of low level access to make it even "faster" and give people more capabilities, because if the web can't have access to everything, someone somewhere loses billions in potential revenue as the users don't get their movies and web games. It will leak like a sieve.

Re:Guys, you're losing it

[Demonoid-Penguin]

Now that we've finally ditched Java and Flash?

They have? It's official? Yay!! Hey code monkeys and desk bunnies - get me a case of beer and take the rest of the day off. It's party time - tell the clients we're compiling all day.

Re:Guys, you're losing it

[Anonymous Coward]

Remember Flash websites? Welcome to "canvas" websites. Who needs DOM when you can run bytecode fast enough to paint your own GUI in a full page canvas element?

Oh look, didn't take long.

Re:Guys, you're losing it

[Anonymous Coward]

Obligatory xkcd:

https://xkcd.com/927/

Re:Guys, you're losing it

[LifesABeach]

Crappy websites are slow because they use bullshit like jQuery and 10 other libraries and don't take the time to remove stuff they don't need.

It would nice to have a utility that would identify javascript's unused variables and uncalled functions; other than the generic line delete.

Re:Guys, you're losing it

[Dutch Gun]

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.

Re:Guys, you're losing it

[swilly]

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.

Re:Guys, you're losing it

[Anonymous Coward]

Even the simplest web sites are slow as molasses

For example?

Re:Guys, you're losing it

[Anonymous Coward]

> This "bytecode" is javascript. Period

It is not javascript, anymore than JVM bytecode is java. It can be scala, groovy, whatever. You're mixed up sir. -1

Re:Guys, you're losing it

[viperidaenz]

Java byte code contains no version.

You've confused it with Class versions.

Re:Guys, you're losing it

[Anonymous Coward]

if you use native code you should be aware that JNI libraries are not guaranteed to work across major JVM versions.

JNI is a C interface, even if it has C++ wrappers the code should stay compatible unless they break the API. I have never seen a JNI library declare a required JVM, only 32 bit, 64 bit or other CPU architecture specific issues.

Re:Guys, you're losing it

[swilly]

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.

Re:Guys, you're losing it

[swilly]

I believe that some of the details in jni.h changed from 1.3 to 1.4. Perhaps a change to how JNIEnv was defined? A quick Google shows that the JNI version did in fact change then, but every page describes launching a JVM from within C/C++ code (which does use the JNI version information).

It is possible that my memory could be faulty (it was a long time ago after all) and that the problem was with launching a JVM from native code. Either way, my point stands. It is possible (however unlikely) to upgrade the JVM and have running JNI code break.

Re:Guys, you're losing it

[jdschulteis]

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

Re:Guys, you're losing it

[Anonymous Coward]

> This "bytecode" is javascript. Period.

Wrong. JavaScript is defined by ECMA as consisting of UTF-16 text (which bytecode ain't).

Re:Guys, you're losing it

[Shirley Marquez]

Java bytecode should always be compatible across platforms, and they have done a good job of keeping that true. There may be rare cases of compatibility issues but I haven't heard of them.

Native code is another matter entirely. That will fail if you move to a different architecture, as could happen if you moved from an old PowerPC Mac to a newer Mac or an x86 system, or when you try to move Java code to a system with an ARM processor. And the libraries have not been as good about maintaining backward compatibility as the JRE has.

Re:Guys, you're losing it

[viperidaenz]

Yes, that's the class file format.

It's not the version of the compiler, it's the class version. A Java 8 compiler can create classes with versions 47 through 52.
You can set that with the -target option of javac

Re:Guys, you're losing it

[Anonymous Coward]

1st, ENCLOSURES are the second name of Javascript. It is the most shitty language ever, except, of course, brainfuck. Oh, sorry, brainfuck is not so bad.
So if you using Javascript, You'll use enclosures.

2nd, Javscript is a very bad VM. why? because it is slow, it takes a lot of memory, it is not safe: it can load untrusted scripts, for example. It is overcomplicated: compare to JVM with 200 bytecode commands and simple behavior.

3rd, it is a second things from Google which is bad. The first one was Dalvik.

Re:Guys, you're losing it

[Anonymous Coward]

It is not possible at all: because of so called "flexibility" a particular web site can always append something new into list of javascript chunks. Therefore there is no "unused variables". Again, I've spend 6 years on this language. I've tried hard, and I had to switch to native code in Firefox extensions. Javascript must die.

Re:Guys, you're losing it

[Anonymous Coward]

JavaScript is not particularly slow or big compared to Java or Python - those complaints are largely a thing of the past.

V8 is from Google, but Google didn't invent JavaScript.

WTF with the new comment links?

[Anonymous Coward]

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?

Re:WTF with the new comment links?

[Anonymous Coward]

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

Completely unnecessary

[fishscene]

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.

Re:Completely unnecessary

[NotInHere]

"The Cloud" needs this. Microsoft for example has used asm.js inside their office online product.

Re:Completely unnecessary

[Anonymous Coward]

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.

It is not well enough, HTML remains a sad joke for real applications. Yes, you can get it to do what you want, but for anything even remotely complex it remains an exercise of shoving a square peg into a round hole. We are easily 10 years behind where we could have been because the standard is too high level, too ambiguous, and unnecessarily combines the concerns of machine readability with those of human-readability. The human-readable standards should have been many and varied, serving many markets and many purposes, driven by market forces. Instead, we're still working with this POS markup standard controlled by a committee. This is all because we lack a lower-level standard, one designed exclusively for machines that human-readable products can target.

Re:Completely unnecessary

[Anonymous Coward]

Bytecode has a lot going for it. Besides being easy to transmit and parse it's also easier to reason about the code and perform transformations and validations. Granted this argument goes for any statically typed language so really what we're trying to leverage here is static typing.

Dynamic typing is a heaping pile of crap.

Re: Completely unnecessary

[Anonymous Coward]

Ignorant rant. Go look at history and where html came from and why it succeeded early on. It was never meant to be a page layout description language like PDF or latex.

Re: Completely unnecessary

[Anonymous Coward]

How is that an ignorant rant if that's exactly my point?

Great, another attack vector

[Anonymous Coward]

Just what we need, another browser executable language to aid in drive-by malware. And i'll bet it'll be the kind to execute without prompts too. Activex mark 2 perhaps?

Re:Great, another attack vector

[viperidaenz]

byte code is not executable. From a security perspective, its not any different than source code.

Re:Great, another attack vector

[Anonymous Coward]

Actually, this runs in the JavaScript VM, with all the same restrictions that JS has. Now, that may still be too many for your taste, but it is better than Java or Flash.

Re:Great, another attack vector

[Anonymous Coward]

Uhh, No?

Byte code is data that tells an interpreter, (in this case a web browser), what instructions to perform on the host system, and in what order to perform those instructions.

The only difference from native executable code and byte code is that the latter must be used to DYNAMICALLY generate the needed instructions at run time, where as in the former the instructions are already generated at run time.

If you want an example:

(Horrible-oversimplififed)Compiled Executable code:
ld r0, 0x1 (Load the value 1 to register 0)
ld r1, 0x0 (Load the value 0 to register 1)
add r0, r1 (Add the value in register 0 to the value in register 1. (Both registers now have the value 1 in them.))

Byte code:
load 1 var0 (Load the value 1 to variable 0)
load 0 var1 (Load the value 0 to variable 1)
add var0 var1 (Add the value in variable 0 to the value in variable 1.)

The byte code looks almost identical to our (fake) compiled code, but the machine will not be able to do what we want with the byte code until it gets interpreted. So unlike the compiled code (which executes instantly) the code that handles the byte code is something like this (In horible-pseudocode):

(Horrible-interpreter):
struct byteToMachineFunctPair{
    int byteCodeID,
    int (*hostOpcodeFunction)(some arg struct);
} byteToMachineFunctPair_T;

byteToMachineFunctPair opcodes[] = {{add, Some function for the host add instruction}, {load, some function for the host ld instruction}};

int Exec(const int byteCode, (Some arg struct))
{
     int ret = ILLEGAL_BYTECODE;

     for (size_t x = 0; (x < (sizeof(opcodes) / sizeof(byteToMachineFunctPair))); x++)
     {
          if (byteCode == opcodes[x].byteCodeID)
          {
              ret = opcode[x].hostOpcodeFunction(args); /* The function that is called here is where the host would actually execute the current byte code instruction. */
          }
     }

     return ret;
}

int main()
{
    int ret = UNKNOWN_ERROR;
    size_t currentByteCodeInstruction = 0;
    size_t totalByteCodeInstructions = 0;

    <do whatever to read in the byte code.>

    for (; (currentByteCodeInstruction < totalByteCodeInstructions) && (ret != ILLEGAL_BYTECODE); currentByteCodeInstruction++)
    {
          /* This loop must execute for each byte code instruction that we want to execute. Only one byte code instruction is executed per loop execution. */
          ret = Exec(currentByteCodeInstruction , <some structure for holding the arguments to the current bytecode instruction.>);
    }

    < clean up >

    return 0;
}

Sorry for the mess, but basically the point is for each possible byte code instruction you can execute, you need more compiled code to execute it. That compiled code is then triggered when the bytecode for it is read by the interpreter. So the bytecode triggers compiled code on the host system and therefore determines the actions that the interpreter will execute on the host. I would very much call that byte code executable. Source code, on the other hand, is useless until it is compiled, or is itself ran in an interpreter. (In which case even source code is bytecode in that sense.) As such due to the increased complexity of the overall task, there is more room for security vulnerabilities.

Re:Great, another attack vector

[Goaway]

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.

Makes Perfect Sense

[cmorriss]

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.

Re:Makes Perfect Sense

[goruka]

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.

Re:Makes Perfect Sense

[Anonymous Coward]

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.

Re:Makes Perfect Sense

[Anonymous Coward]

It has that story covered. This is basically JavaScript in a binary format, that has a little processing done to make it easily consumable by the JavaScript VMs. No new plugins, the polyfills will be in JavaScript or asm.js. This is like an alternative to asm.js. In a binary format, with a text transform available. And a source map.

Re:Makes Perfect Sense

[Anonymous Coward]

The problem is just that PC security is fucking ridiculous. No one should be forced to choose between giving any application they run the ability to do anything they themselves can do on the computer, or simply not running the application at all. What the hell is the point of having a computer if you're not going to run software on it? It's useless without software, and so the fact that our computers can't safely run software is insane.

There's no reason that kids shouldn't be able to download any application that claims to be a game and run it without the dumbass OS allowing that application to do everything to the computer that the kids are allowed to do. Most software would be just fine with no more access to the system than a single folder in which the application can store its own data, and access to a file open/save dialog which can be used to request access to other files on the system like the user's "My Documents" folder in case the user wants to load or save files. The only applications that require access to any random file they care to access are file browsers and archive utilities, but those come with the OS. No software that the user installs should be able to do that.

Re:Makes Perfect Sense

[jaa101]

You're forgetting the big advantage of web apps: they are cross-platform. Also, they are not only zero-install, but they can also be continuously updated on the server without needing auto-updaters or patching on users' machines.

Re:Makes Perfect Sense

[delt0r]

Lets be clear. If it is as general as js it won't be safe. There will be bugs, there will be issues, there will be stupid users that click "Yes debit my credit card $1000 and upload all my personal information.

Sure there will be sandboxes, but they have bugs and errors too.

Re:Makes Perfect Sense

[Daniel Hoffmann]

While I agree with your overall vision this hypothetical sandbox would benefit greatly for being inside the browser itself because browsers are crossplatform.

Re:Makes Perfect Sense

[Anonymous Coward]

You're forgetting the big advantage of web apps: they are cross-platform.

That's not an advantage, that's a disadvantage. I only use one platform. Apps should tailor themselves to my one platform not be a one size fits nobody that web apps are.

Re: Makes Perfect Sense

[Anonymous Coward]

Yep, because everybody works just like you.

Re:Makes Perfect Sense

[tepples]

The only applications that require access to any random file they care to access are file browsers and archive utilities, but those come with the OS. No software that the user installs should be able to do that.

"Nobody needs a specialized file browser. Nobody needs a specialized archive utility." I disagree. But those could still be worked into your security paradigm by prompting the user to select his home directory in File > Open and File > Save when the application is installed.

The 2010's answered the phone

[Anonymous Coward]

We are not giving back, so buzz off.

Java

[xdor]

Have you run a Java applet lately? Or maybe you'd prefer Silver-light?

I think Adobe had something called Flash that's pretty popular too..

Re:Java

[Anonymous Coward]

The 'Internet Virtual Machine" used to work well... a C/C++ bytecode environment.

http://sourceforge.net/projects/ivm/

Back to the future ..

[nickweller]

Java virtual machine (JVM)

Re:Back to the future ..

[non0score]

No thanks. I don't want a VM that has mandatory built-in GC and a bunch of other nonsensical limitations. Provide me one which I can allocate and commit virtualized memory and a safe method for system access with all the facilities/opcodes of an ideal modern multi-core processor.

Re:Back to the future ..

[Anonymous Coward]

You want a world wide implemented VM that does not have GC - you, sir are mad!

Re:Back to the future ..

[delt0r]

So all web browsers must use this mandatory memory model regardless of underlying platform? Does JS give you access to this? You use those opcodes in normal applications?

I have my doubts.

Re:Back to the future ..

[tepples]

But I don't want to have to opt out of Yahoo! on each security update.

The Web needs a lot of things

[Livius]

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.

Re:The Web needs a lot of things

[quietwalker]

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.

Re:The Web needs a lot of things

[viperidaenz]

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

Re:The Web needs a lot of things

[Anonymous Coward]

Hahahahahahahhah

Re:The Web needs a lot of things

[Anonymous Coward]

It must be wonderful spending hours writing an ad-hoc router for each SPA.

Or maybe you are just talking about web sites and not web apps.

Re:The Web needs a lot of things

[exomondo]

The humor was obviously going to be too subtle for some people.

Re:The Web needs a lot of things

[Anonymous Coward]

If you only have a hammer, everything looks like a nail. Programmers make fun of people who say they've programmed HTML, but then the same programmers actually try to turn websites into programs. How would you like a web that works like apps, with access to your location, emails, contacts, persistent storage, etc.? But instead of permissions and app stores you get: nothing - every website just loads and runs whatever code its authors decided on. Welcome to the Web 3.0 (version number symbolic, we're agile).

Re:The Web needs a lot of things

[Anonymous Coward]

"What we need is a language with flow control, variables, functions, templating, the whole 9 yards."

Fuck you! I don't want to have to run such complex code off off the internet where i have no control over it at all.
Your idea will fuck up the internet. Seriously.
Just look at the shit that is possible with the current limited set op external commands that people run daily off off the net. Now imagine this problem growing exponentially. For one, your idea would not survive a day without a proper virus scanner and such.
It is a horrible idea to give external parties so much control over your computer through a webbrowser.

Re:The Web needs a lot of things

[TheDarkMaster]

Well done... Very well done :-D

Re:The Web needs a lot of things

[quietwalker]

This is not anything we're not already doing, the difference is that right now it's incredibly difficult to do well, and the result is an intractable mess. Markup - and CSS is just an externalized form of markup - lacks any real power. It's simplistic, which makes it approachable, but not very flexible or adaptive. In order to achieve even simple goals, we're using fairly complex and increasingly obscured and inflexible markup. When that fails, we turn to javascript to provide liquid layouts that work, and cart this baggage of per-page non resusable javascript around with us, all of it ready to break as soon as we make any changes - or use a viewport we didn't consider.

What I'm suggesting is that we provide the same controls we have for generating a user interface for local software in web browsers. That means being able to programatically adjust layouts, styles, etc, without having to wrap javascript around them to provide for a responsive interface or implement common layout requirements. It means doing all the things we already do, but in a way that increases readability, maintainability and future modifications.

Basically, it means internalizing something like flash, without the proprietary nature and other detriments.

That's pretty much what this WebAssembly bytecode would do, and what I've been advocating for.

What you're talking about seems to have ... absolutely no basis on either the article or my comment. I'm not even sure what it is you're suggesting. Letting other people run any program on your computer through your web browser? That does sound stupid.

Here's a FAQ for slashdotters

[goruka]

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).

Re:Here's a FAQ for slashdotters

[Anonymous Coward]

D) It' s a low-level bytecode, [...] so it can run any language.

That right there is the most interesting bit for me. It could give us a viable exit strategy from javascript.

Re:Here's a FAQ for slashdotters

[NotInHere]

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.

Re:Here's a FAQ for slashdotters

[goruka]

You are right, I used bad wording, meant to be that it's intended to be a w3c standardization effort.

Re:Here's a FAQ for slashdotters

[firewrought]

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.

Re:Here's a FAQ for slashdotters

[Anonymous Coward]

It is needed as a new vector for malware as java and flash are becoming less supported by browsers, by choice, due to jaded users.

Re:Here's a FAQ for slashdotters

[rHBa]

Nice technology, not sure if wasm will catch on as a name though. It sounds too much like a euphemism for some fun you might have on your own...!

Re: Here's a FAQ for slashdotters

[Anonymous Coward]

My thought exactly. I would dearly love to be able to compile from a sane language instead, like c++.

Re:Here's a FAQ for slashdotters

[Anonymous Coward]

No, it relies on the same browser security model as Javascript, so It's as dangerous as having Javascript enabled

So in other words... YES, it is unsafe.

Re:Here's a FAQ for slashdotters

[Anonymous Coward]

wasm.org? =-)

Re: Here's a FAQ for slashdotters

[Anonymous Coward]

Its targeting c and c++ first, but since it is implemented in LLVM, it will quickly gain support. It also wants other compilers to adopt it.

Re:Here's a FAQ for slashdotters

[Anonymous Coward]

Actually the compilation model is basically the same as asm.js, and will be implemented using the same infrastructure. Think of WebAssembly 1.0 as a binary syntax for asm.js.

Re:Here's a FAQ for slashdotters

[peppepz]

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.

In other words, it's exactly like Java but instead of being designed by a software company, it's being introduced by personal data sellers, ad designers, NSA henchmen, DRM paladins, government lobbyists and walled-garden tenders. And unlike Java, it's going to be used by every single web page and we won't be able to uninstall it. Sounds great, what could possibly go wrong.

Re: Here's a FAQ for slashdotters

[Anonymous Coward]

Putting aside the question of the sanity of C++, you can compile it down to JS today using emscripten.

Granted, it would probably be faster with a bytecode JVM, but it may already be fast enough for you to use today!

Re:Here's a FAQ for slashdotters

[Goaway]

In other words, it's exactly like Java

Point A: Unlike Java.

Point B: Depends on your definitions, but fairly unlike Java.

Point C: Unlike Java.

Point D: Unlike Java.

Point E: Unlike Java.

How you can be given five different ways that wasm is unlike Java and conclude that it is "exactly like Java" is not easily comprehended.

Re:Here's a FAQ for slashdotters

[peppepz]

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?)

New attack vector

[tekrat]

Nice idea guys, but unless Browsers REFUSE to run code of any type (including Javascript and Java) without some kind of checksum confirmation, the whole framework will be open to man-in-the-middle malware insertion.

Re:New attack vector

[goruka]

Have you ever heard of https?

Re:New attack vector

[mwvdlee]

Because checksums can't possibly ever be hacked!

Yea something other than JS

[MightyDrunken]

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!

Evolution of PNaCL, asm.js

[Guspaz]

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.

Re:Evolution of PNaCL, asm.js

[Anonymous Coward]

Merged? asm.js was a temporary hack and it's being replaced by a proper PNaCl-like solution. What I wonder is if WebAssembly is a technical improvement over PNaCl, or is it politics? I.e. everyone knows that PNaCl is the way to go, but competitors are jealous they didn't come up with it, so PNaCl developers accepted a name change and involvement of competitors to let them save the face.

Re:Evolution of PNaCL, asm.js

[Goaway]

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.

Why not improve Java?

[drolli]

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

Re:Why not improve Java?

[non0score]

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

Re:Why not improve Java?

[Anonymous Coward]

Not legal BS at all, but the simple fact that the JVM isn't a good fit, and would be a lot more work. The JVM is never really going to support lower-level languages like C++ well, no matter how much we wring our hands about it. And since we need to keep supporting JS, and current JS engines are already en route to being more general-purpose VMs, it's a much easier sell to just keep going in that direction (but toward a common goal) than it would be to get people to have to insert a second whole VM, and then try to merge the two together. Which is also why PNaCl failed to gain acceptance.

Feh. The Java sandbox, Part II

[msobkow]

Anything which tries to run a "binary" or bytecode in the browser is going to be vulnerable to sandboxing issues. It doesn't matter who writes it, it doesn't matter how it's "designed" or "architected", there will be vulnerabilities. Hopefully there is a better and more efficient patching process than there was for the much-hated Java sandbox, but no one should fool themselves that this is a "secure" approach for web applications.

Yeah, close the web even further

[Anonymous Coward]

One of the nice things of the web is that teens learning there little way about computers can look at the JavaScript source code and often figure out how some little trick is accomplished and from there gain insight in how programming works and inspiration for new tricks. Much the same as when we were punching in lines of BASIC from a magazine into a computer that didn't support much beyond 40x25 green & white characters.
I think this change would result in a lot of JavaScript being replaced with essentially a kind of assembler which will be really tough to untangle, especially for newbies. And I think that results in a kind of digital desertification.

Re:Yeah, close the web even further

[Goaway]

This will actually make asm.js code more readable than it is right now.

/Oblg. Birth & Death of Javascript ...

[UnknownSoldier]

We are slowly moving towards this nightmare ...

https://www.destroyallsoftware...

So, I had a thought about this a while back

[erapert]

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...

Re:So, I had a thought about this a while back

[TechyImmigrant]

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.

Re:Feh. The Java sandbox, Part II

[Anonymous Coward]

You don't seem to realise that this doesn't add anything which isn't already possible with JavaScript. Downloading bytecode (as with Java) versus downloading source code then compiling it to bytecode (as with JavaScript) makes no difference to security. It's what that bytecode can do which matters.

Java's problem wasn't the addition of an interpreter. Java's problem was the addition of a ton of extra native functions which could be invoked from that interpreter.

This effort doesn't have that problem because the only functions available to the bytecode are those already available to JS.

byte code is not executable?

[Anonymous Coward]

You obviously do know what you're talking about.

Guess what -- machine code isn't executable either. As winword macro language (or VBA or however its mutation du jour is called these days) -- those aren't executable either.

But take a lesson from history -- all of those, and the Java VM make for wonderful malware delivery platforms.

Remember the last big holes in the Java VM? Some obscure introspection stuff tacked on the oh-so-type-safe VM opened them up.

Of course, JPEG or WMF (remember this one) or any sufficiently complex format can do that too, but the task gets significantly more complicated if you include an execution model (be it real or virtual, that makes no big difference) in the mix

Re:byte code is not executable?

[Anonymous Coward]

You obviously do know what you're talking about. Guess what -- machine code isn't executable either.

Since an "executable" file consists of machine code, I'm going out on a limb and guessing you don't know what you're talking about either.

Here we go again...

[Anonymous Coward]

Everyone making the same obvious complaints about an obvious click-bait article, with little to no interesting conversation or debate.

Moreover, replacing "read more" with "share" is one of the more fucked things i've ever experienced. I have been happily clicking away in the lower left for many years. To use that against me for monetary gain is repugnant.

Fuck dice and your trying to monetize my decades of lurking on slahdot.

At Last

[MichaelSmith]

Its about 1 billion times better than minified js.

Hmmm

[gladius17]

I'm sensing a systemd joke in here somewhere.

Too late.

[gladius17]

Your idea will fuck up the internet. Seriously.

The internet is already fucked up. Seriously.

After reading all the comments in this discussion, it's clear to me that nobody here has the final word on this subject.

A few have posted their ideas which approach the truth, and are being blasted for it. I love it. Makes me sleep a thousand times easier at night.

Not going to explain to you why you're wrong. I can guarantee you'll figure it out eventually; when the right product hits the market.

Re:Feh. The Java sandbox, Part II

[msobkow]

Yeah, and because the functionality is actually needed, with JavaScript you get a bunch of downloaded "extensions" that may or may not have vulnerabilities of their own, or roll your own code, which is even more likely to have bugs.

People keep re-inventing the wheel and insisting that their "new" invention isn't vulnerable to the same problems as those of the past. After 35 years of programming, it is just sickening to see the same arrogance from generation after generation of programmers.

A solution in search of a problem

[Millennium]

"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?

Not bytecodes

[chris-chittleborough]

If by bytecode you mean 8-bit instructions for a stack machine, such as Python and the JVM use, then WebAssembly is NOT NOT NOT a bytecode. In fact, it is a concise binary encoding of a program in AST form. The team are working on a polyfill for existing browsers which will translate the AST into Javascript for execution. Future browsers will be able to JIT-compile the WebAssembly in much the same way as they JIT-compile asm.js or its equivalent.

Basically, WebAssembly is a distributed compiler infrastructure for the web, where browsers get to see a pre-parsed top-down view of a program instead of the bottom-up view that the JVM gives. Low-end devices will be able to quickly translate the AST into something that runs relatively slowly; browsers etc on high-end devices will be able to do lots of optimization.

Further reading:
  * https://brendaneich.com/2015/0...
  * https://github.com/WebAssembly...

BTW, the really scarey thing to be learned here is near the top of that FAQ: "pthreads ... are coming to asm.js". Yep. Asm.js will support pthreads. And people will write code that uses pthreads. In your browser.

New Thing for Hackers to Attack

[SwashbucklingCowboy]

Great... Just what we need... Another virtual machine for hackers to attack...

Re:Feh. The Java sandbox, Part II

[SwashbucklingCowboy]

But one set of injected code works everywhere with this. Not so with JavaScript.

And now the disadvantages

[svdb]

While the advantages are significant, let's not forget about the disadvantages:
* There will be fewer browser add-ons which extend the functionality of a website, as it will be a lot harder to figure out how the code works.
* It will no longer be possible to inspect the JavaScript-code to see how it works and learn from it.
* It will no longer be possible to inspect the JavaScript-code to look for security problems.
* It will no longer be possible to inspect the JavaScript-code for abuse of your privacy.
* It will be easier for malicious sites to run undesirable code in your browser undetected. (Such as Bitcoin miners.)

Targets C++ again

[clenhart]

The problem with asm.js (and now WebAssembly) is it targets C++ delevopers. No one who works on the web codes in C++. The best thing they can do for adoption is to compile from a langauge that web developers already use: C#, Java, ruby, python, etc. I'd love to use something like this, but I can't expect my coworkers to learn C++ and the company to buy C++ tooling.

Re:Targets C++ again

[Anonymous Coward]

I don't think it has to. As long as the intermediate language is flexible enough to represent most common programming structures, I could see browser applications being written not only in JavaScript, but Perl, Python, Ruby, PHP, Lua, VBScript, Go, you name it.

Multiple platforms

[tepples]

In the end you'll wonder why you don't just download the EXE.

Because you can't easily run an EXE on anything but an x86 PC running Windows, or in some cases an x86 PC running Wine.

Platforms other than yours

[tepples]

I only use one platform. Apps should tailor themselves to my one platform

Now watch as the majority of app developers tailor their apps to platforms other than yours.

[To continue reading this comment, install Conglomo Reader. Available exclusively for Xubuntu.]