Hooray! Can't wait to use some real language for web apps finally! We might be at the brink of a revolution due for a long time!

Serious question, because a lot of people have had this sentiment; what is it you think you'll get from WebAssembly as far as new languages that you don't already get from transpile-to-JS languages today? There's everything from very dynamic languages like Opal to typed languages like Elm. What else do you expect?

Efficiency and ease of debugging? Just because it's possible to transpile to JS doesn't mean the resulting code will be fast/responsive or easy to debug. Which in turn means it won't be used for significant projects.

Debugging will use SourceMaps which already exist today. As for efficiency, I haven't read anything that suggests WebAssembly will be more efficient than asm.js, why would it be?

Try reading this: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

"Why: asm.js is great, but once engines optimize for it, the parser becomes the hot spot — very hot on mobile devices. Transport compression is required and saves bandwidth, but decompression before parsing hurts."

Imagine you create a JVM or CLR to WebAssembly converter. All languages and tooling available for them are instantly available for web. Life's good ;-)

Exactly! I've been doing the happy dance for 15 minutes and my wife, after looking at me a bit funny, totally understands.

The article states the "engineers on the webkit project" are also in on this standard. Does that not imply that Apple is also backing this?

If you cannot prevent something, you might as well be a part of it. Unofficially.

Sorry but without Apple a technology like this would go nowhere. Half the mobile traffic on the web comes from iOS and is significant enough on Desktop. And is there something Apple has done with WebKit to deliberately prevent a technology from being adopted ? They supported WebGL for example.

This technology is backwards compatible (at least at first), so a particular vendor's support is not needed, in the short term.

Apple doesnt give a shit about native apps vs web apps. Recall that the original plan for 3rd party apps on the iPhone was web apps only--they only allowed native apps because so many people clamored for them.

JavascriptCore is a top-notch javascript engine for the web. If Web Assembly takes off, Apple will just integrate Swift with it, ship a low-power, high-performance engine, and keep selling a ton of devices.

Yay! Is HTML5 winning war on smartwatches yet? Sorry, but the native apps are much more than some language or binary code.

It would also be the end of user side scripts. It will enable the worst of Flash, Silverlight, Java. Horrible DRM schemes and other user hostile features will be built with this. It's a step back.

This will be created by google and microsoft. Be sure they'll find a way to include DRM inside.

How does this mean the end of native apps ?

You still have network issues such as latency, download limits, black spots etc to deal with.

And personally I don't like the idea of sending my contacts, photos, mail, calendar etc to every third party under the sun just to do anything.

The web has had offline capabilities for years, now with ServiceWorkers it's even better. This argument no longer holds water.

Event better is "might work, sometimes"?

Huh? What do you mean exactly by this?

I think the author is referring to using Swift instead of phonegap/cordova/transpilers, since performance will be improved and you're not limited to just javascript as the originating language.

Native apps give you many complex native libraries including UIs.

You do realize Apple is also part of the effort?

https://bugs.webkit.org/show_bug.cgi?id=146064

Apple is its own third worst enemy (after Google and Microsoft).

Not really you still need to deal with the DOM and Web apis. This is certainly the end of javascript however.

I don't think so. I think compiled and interpreted languages both have a role to play in web applications, just like they do on the desktop. edit: and on the server.