21 ms·
Google, Microsoft, Mozilla and Others Team Up to Launch WebAssembly
- eklavya 11y agoYay!!! Choices, choices, choices. The future is bright and full of opportunities.
- 6t6t6 11y agoThis is important because that could mean the beginning of the end of JavaScript. But also it means the end of the native apps. Apparently Microsoft and Google are playing hard against Apple.
- jugad 11y agoThe article states the "engineers on the webkit project" are also in on this standard. Does that not imply that Apple is also backing this?
- M8 11y agoIf you cannot prevent something, you might as well be a part of it. Unofficially.
- threeseed 11y agoSorry 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.
- Touche 11y agoThis technology is backwards compatible (at least at first), so a particular vendor's support is not needed, in the short term.
- hliyan 11y agoI 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.
- bitL 11y agoHooray! 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!
- andresmanz 11y agoExactly! I've been doing the happy dance for 15 minutes and my wife, after looking at me a bit funny, totally understands.
- Touche 11y agoSerious 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?
- wizeman 11y agoEfficiency 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.
- Touche 11y agoDebugging 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?
- cicero 11y agoTry reading this: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ 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."
- rimantas 11y agoYay! Is HTML5 winning war on smartwatches yet? Sorry, but the native apps are much more than some language or binary code.
- threeseed 11y agoHow 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.
- qooleot 11y agoI 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.
- wordbank 11y agoNative apps give you many complex native libraries including UIs.
- Touche 11y agoThe web has had offline capabilities for years, now with ServiceWorkers it's even better. This argument no longer holds water.
- aikah 11y agoNot really you still need to deal with the DOM and Web apis. This is certainly the end of javascript however.
- eddieplan9 11y agoYou do realize Apple is also part of the effort? https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064
- omaranto 11y agoApple is its own third worst enemy (after Google and Microsoft).
- snowwrestler 11y agoApple 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.
- orkoden 11y agoIt 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.
- gbersac 11y agoThis will be created by google and microsoft. Be sure they'll find a way to include DRM inside.
- estefan 11y ago"The team notes that the idea here is not to replace JavaScript, by the way, but to allow many more languages to be compiled for the Web." Yeah, good luck with that. Ta ta Javascript :-)
- EugeneOZ 11y agoI hope Dart lang team will jump into this wagon as one of first users.
- sanxiyn 11y agoJIT (generating code in memory as data and jumping to it) is one of a few things not very well supported in asm.js and presumably the initial version of WebAssembly, so Dart probably can't use the initial version and should wait.
- M8 11y agoDart and TypeScript will be as irrelevant as JS. Why Dart if you can have Go/Scala/F#/Haskell/Ruby/etc. compiled to WebAssembly?
- sanxiyn 11y agoIf. All languages you listed need GC, which won't be in the initial version of WebAssembly. In other words, you won't be able to compile Ruby to WebAssembly any time soon. You will be able to compile Ruby implementation to WebAssembly, but you can already compile that to asm.js. That is different from compiling Ruby to WebAssembly.
- rplnt 11y agoYes and no. You can have native VM for running WebAssembly's Ruby VM... Oh my god, that sounds horrible as I wrote it.. but it can certainly be better than asm.js.
- EugeneOZ 11y agoIn comparison with TypeScript, Dart has different semantic and less legacy debts than JS. And I think the whole point of WebAssembly is to have a choice, not "perfect language".
- deleted 11y ago[deleted]
- FooBarWidget 11y agoThat comic doesn't hold if all the major parties support the new standard.
- EugeneOZ 11y agoBrendan Eich deserves big respect for his help with WebAssembly. Thank you! And, of course, thanks to all involved. WebAssembly also can be new JVM for desktop apps and widgets.
- weland 11y agoAt this rate, I predict that about ten years from now, they'll just ditch the bloody memory-leaking browser and just ship out a VM and a language that will have a small GUI library with a DOM-like organization in the standard library compiling for it. Sure, there are going to be nitpickers who will point out that we had that in 2005 and it was called Java, but what do they know about innovation.
- andybak 11y agoI'm aware you're being satirical but it's an interesting argument which I discussed with a friend yesterday. Java-in-the-browser wasn't a terrible idea per se. Some aspects of it were poor but the tech landscape back then was very different both in capability and in politics.
- pjc50 11y agoIndeed. The JVM-in-applet downsides (slow startup, memory hog due to fixed heap, unresizable, stuck in its box) were mostly contingent rather than necessary. There's no reason those mistakes have to be made again.
- SteveLAnderson 11y agoI don't think the idea is "Java-in-the-browser" it's "browser-in-the-Java".
- silon3 11y agoWhat we need is declarative html markup again (JS optional). CSS also should be optional. Otherwise, long live adblock, noscript, user stylesheets, ...
- weland 11y agoThat's what we need for web browsers. Unfortunately, every other web designer today seems to think I don't want to read a bloody article, but rather to be engaged by an interactive article-reading application that's basically impossible to distinguish from native applications, except for those eighty quirks that are definitely going to be solved by morehacks.js and those new CSS perversions. Web browser developers seem to cater towards those needs, which is how we ended up with browsers where I can run fifty gazillion floating-point instructions per second in JavaScript but it takes me five seconds to find a bookmark, three of which are spent hovering over the titlebar until I remember there's no menubar anymore.
- BerislavLopac 11y agoAnd how will this affect security and privacy on the Web?
- creshal 11y agoWhy would it? Bytecode is not substantially harder or easier to disassemble and grok than minified and obfuscated JS.
- yAnonymous 11y agoIt will also make malware faster and more difficult to reverse engineer.
- dimitar 11y agoI wonder what the FSF might say about this development.
- kenrick95 11y agoYeah, since it is binary format, will the web start to serve closed-source JS-like scripts?
- andybak 11y agoThere's nothing stopping people distributing closed-source obfuscated scripts at the moment. There's not a massive difference between minified javascript and decompiled asm.js.
- jmickey 11y agoAm I the only one who thinks there actually is quite a difference between minified & obfuscated javascript vs bytecode? Minification & obfuscation can only do so much without changing the logic of the script. Sure, spaces are removed, variable and function names make no sense, but most of the logic is still there just as the developer intended. If we look at compiled Java/C++/Any high level language code, how the application logic is presented is substantially different from the original logic of the application. Making it so much harder to understand how the application works.
- dtech 11y agoI disagree. Obfuscation is essentially the same as a separate compilation and can do as little or as much to distort the original logic as compiling to a lower level language. E.g. an obfuscator could make all method calls into one identical named overload, while a compiler could emit appropriately named subroutines. The compiler preserves the logic better in this case. Minimization is something different, but minimizers do not attempt obfuscation, it is more of a side effect of their goal.
- flohofwoe 11y ago
- tddfuckwitz 11y agoDoes this eventually end up as yet another virtualization layer? How big and bloated does the web stack become before we start again, with a lean protocol and markup language for text documents?
- creshal 11y agoMarkdown over Gopher? Yes please.
- dspillett 11y agoThe lean protocol and markup language will still be there to use though. This just gives us a new tool that is right for a different set of jobs and hopefully integrates well with the other parts when needed.
- creshal 11y agoAssuming HTTP and HTML ever qualified as "lean".
- dspillett 11y agoFair point. CSS too. But they are leaner than piles of javascript which is in turn leaner (at least from a dev stack point of view) than a full compilation stack and process. We have quite a range of useful options for our needs now: * Plain text. Sometimes it is all you need. Just server text/plain via HTTP and be done. Add markdown or similar as you see fit. * HTML+CSS for most occasions because you want to add at least a little style. * Add in a little JS when you need some basic interactivity or because you are presenting a lot of information and the option to hide/collapse some of it is useful to the user. * Add a lot of JS and libraries once you are getting into proper "application" territory rather than just a fancy page of information. * Start compiling form other languages when for your project needs some constructs not available or easily emulatable. * Start considering WebAssembly when your project really really needs the performance gains possible over JIT compiled JS (or you want the binary format for obfuscation purposes) None of those options invalidates the ones before it, so it really does come down to having a good selection of tools and picking the right one for the job. The fact it is all cross-platform (at least it is if you ignore "legacy" browsers like IE6 and Android 2.3.x, don't mind using less efficient polyfills for the not-quite-legacy-yet options, and are careful to remain compatible with a range of screen sizes and (once you introduce interactivity) input methods) and the big names appear to be playing nice enough is icing on the cake. I think we are living in good times in this respect.
- tinganho 11y agoI must say about DAMN TIME!
- sharpercoder 11y agoBob Nystrom argues [0] that a language VM has important advantages over a bytecode VM. His primary argument is development iteration speed. How does this compare to WebAssembly? [0]: https://www.dartlang.org/articles/why-not-bytecode/ https://www.dartlang.org/articles/why-not-bytecode/
- sanxiyn 11y agoWebAssembly (and asm.js) is not really a "VM" as in JVM or .NET in that it does not provide services they do, like GC and adaptive JIT. I think the best description of WebAssembly is a reincarnation of p-code.
- dtech 11y agoIt is very much a VM, in that it executes generic bytecode. Furthermore the Javascript engines of modern browsers (on which this proposal is based) do JIT JS. Not having GC doesn't mean it's not a VM. Quoting the wikipedia article of p-code: > In computer programming, a p-code machine ... is a virtual machine designed to execute p-code
- sanxiyn 11y agoYes, it is a VM, but not "VM as in JVM or .NET". "VM" in Bob Nystrom's article is used as a later sense. Hence the article mostly does not apply to WebAssembly. On the topic of JIT, the whole point of WebAssembly (and asm.js) is that it is so simple that you don't need JIT to execute it. You can AOT it fine.
- bryanlarsen 11y agoWasm is not a bytecode. It is a binary AST.
- no_gravity 11y agoThe WebAssembly team decided to go with a binary format because that code can be compressed even more than the standard JavaScript text files and because it’s much faster for the engine to decode the binary format Are there real world examples of websites where the size of the JavaScript and the time it needs to decode it make up a significant portion of the load time?
- yenda 11y agoGmail ? Google Docs ? And it might also be the final blow on Flash.
- jonlucc 11y agoDid flash need a final blow? I assumed it is still around in small pockets because of projects that are abandoned and casual developers who don't intend to learn a new set of tools.
- bovermyer 11y agoIt's more pervasive and hard-to-kill than you think. At least these days we don't have project managers asking "can we add Flash?"
- monk_e_boy 11y agoGames.
- vidarh 11y agoI have a project where downloading the JS takes about 30s on my 40Mbps home connection.... Maybe not so many "websites", but there a lot of javascript applications will benefit greatly cutting down on the size and parsing time.
- NKCSS 11y agoWhy are you serving 150MB of JavaScript??
- ahomescu1 11y agoEarlier discussion on this topic: https://news.ycombinator.com/item?id=9732827 https://news.ycombinator.com/item?id=9732827
- louhike 11y agoThe Unity team has already made some tests for their Engine with WebGL and WebAssembly and it seems promising: http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/ http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-fe...
- M8 11y agoHopefully we will not need Unity3d to have high-performance C# engines in browser.
- sanxiyn 11y agoHow else you will get C# in the browser? C# is high-level, WebAssembly is low-level, something needs to do lowering. Edit: I don't see how future addition of GC to WebAssembly changes anything I wrote above.
- M8 11y agohttps://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...
- wtetzner 11y agoYou write a compiler from C# to WebAssembly. I don't see how C# is different from any other language in that regard.
- sanxiyn 11y agoI think we are in agreement? Unity3d provides C# to JavaScript compiler. I replied to "Hopefully we will not need compiler to have high-performance C# engines in browser", because that does not make sense.
- wlievens 11y agoUnity is much, much more than a compiler. You'd have to drag a lot of stuff with you and deal with a license.
- yeureka 11y agoWow. If C/C++ code can run at near native speeds on most browsers, specially mobile browsers, this could make a dent on app stores revenues, specially for IAP based games.
- moonchrome 11y agoYou will still be using sandboxed DOM APIs (that adds both overhead and restricted API access), you won't have access to app store stuff like in-app purchases and your adds will be blocked by adblock that will be shipping built-in to browsers.
- UserRights 11y agosecurity nightmares ahead - running random binaries from the web - but wet dreams of privacy invaders of all sorts becoming real.
- rockdoe 11y agoIt will sit on top of the existing JavaScript engines and APIs, so no new security issues there.
- satai 11y agoThis is no issue of language, this is issue of APIs and runtimes. Binary serialization of code has to do very little with security.
- ciupicri 11y agoAs if the parser of JavaScript source code can't have security issues.
- lallysingh 11y agoNo. Categorically not. Is this intentional FUD or can't you discriminate between a program in source and compiled forms?
- UserRights 11y agodoes already a plugin exist that blocks this crap?
- cdnsteve 11y agoSigh, seriously all this front end stuff is becoming a PITA. Maybe it's just me but I still find the web a mess today. Lately I've been feeling the app stores sound more appealing than actual web development. JS this, 5 new frameworks a week that, some byte code tech... All this change is making me nauseous. Time to stick to the back-end I guess, maybe with a pinch of native apps.
- scrrr 11y agoThis came up so quickly, nobody was able to create the WebAssembly page on Wikipedia yet [1], it seems. [1] https://en.wikipedia.org/wiki/WebAssembly
- hodgesmr 11y agoWhy stop with WebAssembly? Why not address the entire notion that we're tricking document-rendering browsers into being application runtimes?
- wtetzner 11y agoI actually don't see a problem with using a document renderer for applications, assuming it's actually treated that way. The document-rendering of a browser is lower-level than a UI toolkit, and that makes it more powerful in a lot of ways. But we need to be able to build abstractions on top of it to actually build UIs. I think react.js's approach (or something similar) is actually pretty good here. A lot of the problems we run into are people treating DOM nodes as if they were UI widgets, when in reality they are lower-level primitives for drawing and capturing input.
- Touche 11y agoThere's canvas, build your own UI toolkit on top of that if you don't like the DOM.
- avodonosov 11y agoWell, it's not suggested to stop with WebAssembly, it's just aт evolutionary step from the situation formed to this time.
- bovermyer 11y agoThis is very welcome news. Don't get me wrong; I like JavaScript. It has its warts, and it can cause all kinds of problems in the wrong hands, but both of those things are true of all popular languages. However, performance has always been a sore spot for the current JS-to-machine-instruction process. Being able to write code that will execute faster is important, regardless of the language that code was originally written in.
- ssebastianj 11y agoI'm learning Rust and it would be nice to see a Rust powered kernel, just for hack with it a learn a lot.
- gbersac 11y agoThis is the post I created to discuss this on reddit : https://www.reddit.com/r/rust/comments/3abgbo/webassembly_rust_compile_to_web/ https://www.reddit.com/r/rust/comments/3abgbo/webassembly_ru...
- geertj 11y agoDoes this get us integers in Javascript?
- pcwalton 11y agoYes, because you already had them. (It uses the Emscripten tricks to use integers in JS, which VMs readily understand at this point.) It doesn't add Value Objects yet though—that's a separate proposal.
- nickstefan12 11y agoWould it be wrong to interpret this as the possible end of browser focused engineers? It seems to me that consumers have spoken that they prefer native apps (especially mobile ones) that they can quickly find on their phone's home screen. Consumers are using desktop web apps less comparatively to native mobile ones. So rather than people making web apps and then trying to port them to native, we're going to have a bunch of native apps that port to the web? OR ... maybe web goes back to being the defacto standard if people start making insane unity engine powered byte code based web apps that perform like native..
- Animats 11y agoIs the purpose of this to make ad blocking harder? It's much harder to work on an executable form than a declarative one like HTML/CSS. Really, how many useful web pages need to execute much code? Games, sure. Other than that, not so much. Is this trip really necessary? We just got rid of Flash, after all. (And, of course, it's basically Java, round 2. "Write once, debug everywhere.")
- nirajoza 11y agohttp://www.techzigg.com/2015/06/google-microsoft-apple-and-mozilla-team.html http://www.techzigg.com/2015/06/google-microsoft-apple-and-m...
- nirajoza 11y agohttp://www.techzigg.com/2015/06/google-microsoft-apple-and-mozilla-team.html http://www.techzigg.com/2015/06/google-microsoft-apple-and-m...