A WebKit announcement is notably missing, unfortunately. However, it is great to see Edge, even though it is not a surprise, as they have been pushing for WebAssembly from the start.
Standard caveats apply here. It's experimental: a couple bugfixes are already in flight and we're working hard on improving the startup time.
Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with whom we've worked closely with over the past year to make this a reality.
Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't.
From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.
If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet.
Update: Here's a quote from the Microsoft announcement:
"Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case."
You are misunderstanding. A C++ application compiled to wasm is smaller than a C++ application compiled to a subset of javascript.
A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. The best you could do would be to store some kind of compressed representation of the source code, along with a JIT compiler to run that source code. It isn't a sensible thing to do.
Once WebAssembly supports all the features of JavaScript, which is on the roadmap (step 3, "everything else" [1]), it'll be a very sensible thing to do, especially for mobile.
Compiling JavaScript text source code into a binary representation of its AST will save time and space downloading, and time starting up.
You won't need another JIT compiler, the web browser usually already has one. WebAssembly is bytecode and JIT agnostic. Compiling text JavaScript into a binary WebAssembly representation of the parse tree is different than compiling the parse tree to bytecode, or JITting the parse tree or bytecode to machine code. They are complementary layers, and both synergistically useful together.
I can only imagine the possible security exploits available by passing AST binaries directly to the browser, rather than letting the JS lexer/tokenizer and compiler enforce language rules from the source.
A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language.
This compiled/interpreted distinction has gotten quite fuzzy, and it has been for decades now. Smalltalk was always a compiled language with really late binding. It did compile to a bytecode which was interpreted at first, but that became JIT compiled in all but one commercial VM. This all happened over a decade ago.
Also, there is clearly a subset of Javascript programs that could be usefully compiled down to a small, fast, compact machine language program.
But the point is, if you want to compile your JavaScript code ahead of time, you have to ship your own GC and JIT compiler, because you no longer get it "for free" from the browser's JS implementation. There's absolutely no benefit from doing this.
Okay, but why would you compile JS down to wasm, only to have it then use the browser's built-in JS runtime? I see the use for compiling other dynamic languages, but compiling JS via wasm shouldn't be any different than running it via the normal JS engine, aside from potentially having a slightly smaller executable.
Nitpick: What doesn't make sense is 'compiled language'. The term is non-sensical. Languages are not interpreted or compiled, implementations are (sometimes both like cpython). As a counter example, cl-javascript[0] compiles javascript to common Lisp
I think you misunderstand what WebAssembly is about.
As I understand it, it's little more than a binary serialization of JavaScript ASTs. In which case, no, you don't need to ship your own GC with it.
I mean, you could always write a JavaScript interpreter in JavaScript, and then compile that into WASM, in which case, yes, you'd ship your own GC. I don't see why you would feel the need to do that for real world applications, though.
> I think you misunderstand what WebAssembly is about.
I don't, WebAssembly is about C++, primarily. Every design decision has been to support C++. Everything else is an afterthought that will come later. WebAssembly isn't about minifying your JS.
It's C++ first as a convenience, since LLVM is best at C++ and emscripten w/asm is a solid benchmark. It is NOT primarily about C++ just because that's the v1.
That's true of version 1, but supporting arbitrary JavaScript is on the roadmap (step 3, "everything else" [1]). Which will be awesome!
What I'd love to be able to do with tools like Unity3D that compile C# and other CLR languages into asm.js, would be to pass JavaScript objects directly in and out of the C# code so you can manipulate the underlying JavaScript objects directly from C# with little or no overhead.
Right now of course you can implement JSON libraries in C#, but it's indirectly and inefficiently layered on top of the flat memory model of asm.js. I want to be able to use the native JavaScript objects and libraries directly from other languages like C# that compile into JavaScript. That would be ideal!
To do that, asm.js would need a way to store references to garbage collected JS objects somewhere, somehow, using proxies or handles represented in linear memory, opaque reference types [2], or some other magic like that, like Apple's JavaScript/Objective C bridging stuff [3].
My initial reaction was for software with a flat memory footprint, so it really doesn't require garbage collection. Our application could be written in C, if we weren't web developers who are working in JavaScript.
No one wants to do web development in C++ honestly, but they would like the performance.
I could see this functioning really well with webworker once some sort of thread-safe representation is in place for quickly moving objects in/out of said worker... Would be a pretty clean separation of WebAssembly code, and the DOM accessible code by convention... even if sticking to object serialization (JSON), it would be pretty clean...
With IE9 support slipping, it seems to be a no-brainer in terms of support at this point too [1].
I'm also thinking this could be a huge win once it hits node.js (v6?), as this could be a great answer to better binary module support. As binary modules are a bit of a pain to support, and prebuilt binary modules are in a hodge-podge state.
Why would bundling a Javascript engine in a webpage be faster? I guess it's likely if someone were to make an improved Javascript engine, but their effort would be better spent improving the Javascript engines in browsers (affecting all webpages) rather than bundling it as a many-megabyte download into their own webpages.
DonHopkins pointed out that wasm will eventually support serialization of arbitrary js. So you wouldn't need to include the js runtime at all, but still get a much quicker download and parsing.
It really depends on the code. This whole topic is for webpages with scripting that have reached performance bottlenecks, not just an obscure exercise in torture.
> Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?
Similar to asking why would you want to run JavaScript on the server?
There's something to be said for having your code in a single language. People can move to different parts of the project more easily and if you need to run the code in multiple places then you can do so with (mostly) a single codebase.
The real question is why WOULDN'T you compile all your JavaScript to wasm assuming the build process is easy enough. For complex site that already have a build pipeline I don't see any reason to publish minified JavaScript instead of just building it all into wasm for performance reasons (assuming mature debugging tools of course). The only question I'd have is whether you get that much gain by going from JavaScript to wasm or if the browser's JIT compiler can do a good enough job.
Compiling JavaScript into WASM is most likely not going to result in better performance unless you make an extremely good static optimizing compiler, and probably not even then. It's very hard to do the kind of optimizations that JIT compilers do ahead of time, in one single static binary.
Agreed. The entire point of asm.js (which WASM is currently just a compact encoding of) is that it's a simpler subset of javascript that's easier to optimize. If you could transform arbitrary Javascript into asm.js efficiently, then similarly you could also apply asm.js's optimizations to arbitrary Javascript, and the whole asm.js part would be pointless.
Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time. There's also startup time that you're paying with AOT and avoiding with JIT.
> Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time.
The post I originally replied to brought this up in the context of TypeScript with the aside that TypeScript is basically JavaScript. Do you think that using TypeScript's static typing and compiling to wasm could/would be faster than JIT-compiled JavaScript?
To the contrary, I think everyone should touch the DOM when they need the DOM. If this is going to be a platform for more than ads and shitty games, it will need to be able to use the browser's exquisitely engineered ability to do text rendering and layout.
Just like Flash or the JS game platforms that are stupid hacks on top of the canvas element, if people have to implement text rendering without the DOM, it'll encourage putting poorly-rendered text in unusable layouts with squirrely scrollbars. We can do better.
It probably won't happen in V1 but yes, it's incoming. We'll be able to pretty much use whatever we want. When wasm was first announced Brendan Eich made this clear, and a lot of the JS-All-The-Things folks who bet their careers on it were upset.
I'm not sure why, if you like JS, people can keep on using JS indefinitely. My theory on programming is to use the language that I prefer, and worry about everything else secondary. For me that's Python. I've mostly avoided any deep dives on learning JS so it'll be nice to be a part of a budding Python web frontend community when the time comes.
I'm getting somewhat excited about swift. It's quite a modern language syntactically and python/ruby-like productivity may not be out of reach. Yet it leaves managed languages in the dust performance-wise (factor 100x plus), on par with C++.
And the memory management is uses should make compilation to WebAssembly rather straightforward. (... I believe – I have little knowledge of that sphere and welcome any corrections).
Once wasm supports some access to the gc (on the roadmap), It should be feasible. You wouldn't reimplement the entire runtime, but reuse functionality (like the gc) from the js runtime.
Do you have any reference for that? You can already technically use whatever you want and wasm will not remove the need for high level languages also having to supply a (multi megabyte) runtime as there is no direct mapping to wasm instructions unlike with C++ or C.
Eich's comments on HN and on Twitter. It was all discussed when wasm was first announced a while back. I'd dig up the exact source comments from Eich, but at work. You'll probably see enough comments from the wasm folks in this post to verify whatever particular technical specs you're interested in to satisfaction.
Because even a just-in-time compiler is slower than native performance quite frequently. A just-in-time WebAssembly compiler can be guaranteed to be as fast as V8 in practice.
Branch prediction on a CPU can be quite helpful, but if a program stops hitting the same branches it can impact performance. The point of a just in time compiler is that it compiles on the fly, which does take a certain amount of time. That could be loading time for your application.
In any case, the purpose of this development would be to design something that is faster than V8. And I'm specifically speaking of compiling with inferred types or from asm.js or TypeScript, not embedding a VM or a garbage collector or an emulator.
This compiler might only accept programs that would be faster.
Well, you'll need a garbage collector anyway, and with AOT compilation it would have to be conservative (which isn't that much of an issue, but precise collectors are generally a little more efficient).
The problem is that you can't fully trust your type inference. JIT compilers can get away with this because they can escape to the interpreter if a type check fails. With an AOT compiler you can optimize for your inferred type but you still always have to include complete code for the slow path too. At that point 80%+ of your instruction cache is gonna be probably-unused code. You can never eliminate as many type checks as a tracing or block versioning JIT.
TypeScript doesn't help either:
function foo(a: int, b: int) { return a + b; }
window['fo' + String.fromCharCode(111)]('nice ', 'try);
Whoops. TypeScript is (intentionally) unsound, which doesn't help your compilation much.
If AOT compilation were a way to get JavaScript faster than V8, V8 would compile ahead-of-time (well, it would probably compile in the background and use an interpreter on first load, but you get the idea).
asm.js is a different since it is strongly typed and explicitly controls memory layout. It's not JavaScript from the perspective of implementation.
Well, then I should use some regular expressions, a parser generator, AST walker and syntax analyzer, with the help of a few directive comments, to turn my strict subset of JavaScript code into C, and then use emscripten to generate WebAssembly.
Then I will have faster (and smaller) code on platforms that support WebAssembly and regular JavaScript on platforms that don't.
What a wonderful way to deploy JavaScript to WebAssembly for enlightened developers, which doesn't involve a "compiler."
Obviously, we are thinking of different scenarios. My subset of JavaScript may be different than yours, which might be different than asm.js. Asm.js would be great except it isn't idiomatic and having a fixed heap isn't always great. That doesn't mean there aren't middle grounds which are as of yet unexplored. This is sort of a limited area, which is probably why no one's started a project on this yet.
By the window['foo'] argument, minifiers are unnecessary because then you can't use eval().
That is interesting, thx. ... but it seems to me, they failed, because they wanted to mix strong typed js with weak typed ...
"the main problem here was the interoperability with weak classes: we need to allow inheriting strong from weak classes and vice versa"
> turn my strict subset of JavaScript code into C, and then use emscripten to generate WebAssembly.
Well, the problem there is that your subset would be... C. JavaScript without automatic memory management, closures, prototype inheritance[1], and dynamic types isn't really JS anymore.
> By the window['foo'] argument, minifiers are unnecessary because then you can't use eval().
Most minifiers don't touch object properties or global variables for this reason. Closure compiler is the only one that does and it's quite strict (and doesn't work on a lot of JS code because of it).
1. Assuming objects are hash tables in your implementation, you might be able to do inheritance by reference counting a list of parent hash tables but that could get messy.
The code that I have to work with is static. It just happens to be JavaScript. Aside from writing some type casts and a linked list implementation, the standard implementation for a project like this doesn't have to be large. And yes, it boils down to a trivial C compiler.
Also, Uglify 2 modifies global properties if you tell it to, and neither uglify nor closure compiler do well with object properties, which can be renamed.
All of these arguments assume that a developer is unaware or not understanding of the mechanisms that their code uses. It seems no one is interested in using anything other than emscripten/LLVM.
>Because even a just-in-time compiler is slower than native performance quite frequently.
No that's not how it works. The problem with most JIT'd languages is that every variable or field is a pointer, every function call is a virtual call and there are no type signatures to help a compiler. These are the main reasons. If you added structs, nonvirtual functions and type hints you will quickly enter C performance territory (this is basically what asm.js does).
JIT compilers heavily use profiler guided optimizations to avoid the overheads associated with dynamic languages. They can often inline polymorphic function calls because usually 98% the variable points to an instance of type X and the remaining 2% to type Y. Falling back to a normal polymorphic call if the type is not Y. This is something an AOT compiler cannot do.
Yes, it can. You know the part where the JIT decides whether to execute X or Y? That can easily be implemented in a conditional in compiled code with the two code paths, X and Y.
But I'm more interested in the C performance territory. I'm not even interested in cross-compiling code where globals are used or variables change types.
It's possible to strip the functions and properties off of a JavaScript prototype and if it's well behaved, which user code is more likely to be than JavaScript libraries, it can be compiled fairly well.
> You know the part where the JIT decides whether to execute X or Y? That can easily be implemented in a conditional in compiled code with the two code paths, X and Y.
And that's the difference with a JIT compiler: if the value is almost certainly X, then it just emits the code for X and a stub for Y. The stub just bails back into the interpreter. The check is a couple machine instructions and the fast path can be pipelined (since branch prediction is unlikely to fail).
An AOT compiler has to include the full code for both X and Y, no matter how unlikely Y is. AOT compiling dynamically typed languages gets you easily 80%-90% unused code.
Then why isn't your argument against code size rather than performance? Seems like an odd position to take. The fast path would also be branch predicted in an AOT case.
The only difference in this hypothetical is that the slower path would run faster.
Because with 80%+ unused code, your instruction cache is gonna choke.
Also JITs can remove many more type checks, because it knows when a check would be redundant. See e.g. Lazy Basic Block Versioning[1], but existing tracing JITs do quite well also.
Native performance is only better in the cases where you can explicitly control memory layout & access. That's why asm.js runs so fast. You're explicitly translating C/C++ to arrays.
I don't really see how a js -> wasm compiler fundamentally changes things. You're still working in JS which has poor memory placement semantics.
Argh, I see this keep coming up and it really needs to be put to rest.
Compilers don't know how to layout your data. They don't know how you'll access it or the traversal patterns. Your whiz-bang compiler isn't going to strip out class members and AoS from SoA because that's a fundamental data structure problem.
Compilers are great, they fold things down, inline and unroll loops. When it comes to memory placement they can't know your intent and it's up to you to lay out your data appropriately. They might do padding but anything else is going to have memory & complexity implications and they shouldn't make those decisions for you.
I don't know, you have a real mix of arguments here, as do most people. There's nothing a JIT does that an ahead of time compiler can't do without the burden of a larger footprint.
This is really an issue of backend optimization to "make things like asm.js."
For example, there are obvious examples of cases where a JavaScript object's properties and property types would be transparent to a compiler at compile time, with a complete graph of where those values would be stored and used. This would be stored in the WebAssembly stack, analogous to an asm.js fixed array.
The WebAssembly sandbox is designed to run code directly. The JIT is designed to build code to run directly in an iterative fashion. If system designers knows how software is expected to operate, they can make choices to instrument that process and also make software which is designed intelligently.
Java runs in a VM. Someone could write a just in time compiler for .java code that performs well. That's not a sufficient argument not to develop or continue to develop a javac compiler for byte code. Additionally, whether or not a language is designed to use GC doesn't mean there couldn't be research or design into avoiding or augmenting that situation for performance (in the way that a just-in-time compiler would relieve the situation). Nor reason not to build a platform and engineering methodology to deploy to two independent and cooperating runtime environments.
Neither Asm.js and emscripten or C are the end of all things. Neither is dynamicism.
If you compile ahead of time, you can tune your optimizations. With the right tooling you can tell the compiler that a certain path is hot and should be optimized from the beginning, or catch deoptimizations better, or just get rid of the compilation cost. Right now I'm not sure how much practical benefit there is, but there's a lot of potential.
> compiling from ECMAScript to WebAssembly would be a great boon in production.
That's not going to work well, I'm afraid.
JavaScript is a highly-dynamic language, and as a result, requires JITs that do runtime type profiling, type inference, and type-specialized code generation, in order to be fast.
WebAssembly is a low-level, statically typed language. It's like a portable C with a small binary footprint.
Even if you annotate and/or detect some of the JavaScript types at compile time, if you don't have them all, that means compiling JavaScript to WebAssembly will result in code that everywhere does "if this type, do that; if that type, do this". That's going to be bigger in code size than JavaScript currently is. It's also going to run much slower.
If you did type every single thing in your JavaScript program, somehow, then that might work well. But that's not really JavaScript anymore (or even TypeScript, etc.).
It's not asm.js, it isn't C (but it was ported from C), but it's JavaScript and it has no dynamic allocations. No variable uses more than one type. I could hand fashion asm.js and WebAssembly code and tell you which one is faster.
That's the only answer to whether a JavaScript to WebAssembly compiler would be worthwhile.
WebAssembly is a binary representation of the Javascript AST. Optimizations usually happen AFTER it is parsed. That's all WebAssembly is -- the parsed result. Targeting WebAssembly from Javascript is the most natural fit that could possibly exist.
If you want to target WebAssembly, I suggest starting with Rust or some other language that doesn't require a garbage collector.
WebAssembly doesn't have a garbage collector (yet) which is essential for JavaScript and many other high-level languages. Shipping a garbage collector compiled to WebAssembly is going to make downloads much larger, and it's likely going to perform worse than the native garbage collector.
A compiler for a garbage-collected language is probably better off targeting JavaScript, not WebAssembly. There are already lots of languages that do this: GWT, Dart, Kotlin, ClosureScript, Elm, etc. There was already plenty of work to do for a compiler expert even before WebAssembly came along.
The purpose is to limit the number of steps in development.
If only 50% of users are running the WebAssembly version of a product, and 50% are running the JavaScript version of the product, then both need to be stable.
Developing in an unrelated language is unlikely to help.
Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.
Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on.
This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share.
The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.
It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...
The initial release of WebAssembly won't have any support for well-integrated runtimes, which complicates support for any language that isn't C or C++ or Rust. Theoretically you could probably ship the Go runtime with each webpage, but I don't know how you'd interact with the DOM from there.
Well DOM _(from my limited queries)_ is a bit further out anyway. On their design page, DOM and GC are actually lumped together[1]. That being said, i really want DOM access from Rust, so perhaps it's a moot point heh
Interacting with the DOM from C++ or Rust via an opaque handle seems relatively straightforward compared to designing one-size-fits-all GC primitives that will enable multiple GCs to seamlessly interact (because remember, you may very well want code written in Go and Python and Javascript all on the same page, and they'll all want to manage the same DOM).
I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.
WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2].
I think the idea is that WebAssembly apps will normally be closed-source, but browsers will ship with disassemblers, making it easy to inspect the app logic in a common text format.
Then every exe file is open-source, because we have disassemblers. Don't lie to yourself: webassembly is for closed-source applications. They will be compiled by an obscure compiler, so dissassembling back to logical code will be too costly to be practical.
We saw this many times: for v1, disassembler works perfectly and maps 1:1 from binary to code, but for version xxx.0 it's no longer true, because of various tricks and optimizations.
No one's saying wasm apps will be open source, just that there will be a reasonable way to inspect their logic. Of course making sense of certain wasm apps will be challenging. JS code can be hard to follow as well, if it was generated by a tool like GWT, or minified, or obfuscated.
I am agree, that wasm will be on par with generated/minified JS right now, but I predict that wasm will beat JS in future versions. My prediction is based on experience. It is very easy to introduce a binary thing which is hard to map to flat text. I.e. first version of wasm will be 1:1 map to JS, but NEXT versions of wasm will introduce optimizations, which are quite possible in compact binary format but are not possible in flat text format, so 1:1 map from wasm to JS will be broken.
Even if it's easier to obfusfate WebAssembly, does that matter? If you run the 2MB+ JS libraries in se today through uglify.js it becomes almost impossible to understand the macrostructure just by reading the code.
It's only through dynamic tools that we can even begin to understand minified JS today. Those are actually quite excellent: just try by starting the react or relay tools on facebook.
That ecosystem is hopefully not changing, so what remains is simply that the format is now binary. I agree that that makes me somewhat uncomfortable but realistically it doesn't really change anything.
Before, we had asm.js. asm.js isn't very readable. By contrast, Web Assembly has a nice human-readable (though terse and low-level) IR. It even looks like Lisp, if you like that :)
Web Assembly is a small step toward better human inspectability of the compiled blobs your browser is executing, compared to Flash, Java, and asm.js. To be sure, it doesn't mandate that the source be available in the form preferred for editing. But the Web hasn't done that since 1997.
Agreed. It might also be nice to have wasm blobs compiled from open source code supply a standard metadata link to that code (the project's GitHub repo or whatever) so that UAs can offer nice affordances to replace Ctrl-U if they want to.
I don't think the downvotes are necessary here, this is a legitimate question.
Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform.
Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.
Well "just a binary representation" in the same way that .Net's CLR is just converted C#/VB/F# etc...
Unless you know the source language, and have some sort of reverse-compiler (or source maps), then getting back to a readable/usable source isn't so easy. Though that doesn't mean you can't trace through what goes down the wire, it won't be quite as low-level as x86 assembly, but will be lower level than most are comfortable with.
But this is already true today with Javascript transpilation and minification. I have been in the unenviable position of needing to reverse-engineer compressed Javascript for which no "readable" source was available, and even with prettifiers the experience is hardly enjoyable.
Absolutely agreed... one of the reasons that source maps are nice... but if you nuke sourcemaps in production, good luck...
If it's someone else's source, then you may be SOL, just the same, it is what it is... if you're reverse engineering a gui, best bet is to create a clone... if it's an api, better to look into the wire protocol.
I hear this argument a lot. It may have been true once, say 5 years ago.
Today I can already do that -- look at the output of the Google closure compiler with advanced optimizations turned on. Sure it is javascript and not binary, but all comments have been removed, all variables have been given short and meaningless names that are frequently reused and all the structures have been turned inside out.
And I've never understood this argument. Yes, JS allows people to ship obfuscated code. Doesnt mean we should give up and stop expecting readable code.
I am a bit baffled too, but in the end of the day, it's no different from running javascript. Most pages load probably millions of lines of JS and you can't audit it (disclaimer: I totally made up that number). For the security conscious, the only way is to implement very strict JS/cookie whitelisting, which is what I do. For the others, well, I guess it's no different from running JS in the end of the day.
I wonder if this will make it's way into WebKit, and if so its implications for Xombrero, will I have to maintain a seperate WASM whitelist, or disabling JS will disable it too? TBH I plan not allowing even the most trustible website run such code on my computer.
Are there any plans to run WebAssembly outside of a browser? Would it be difficult (once the binary format is nailed down) to distribute a standalone program?
Given that node.js uses v8, and there are a few options for stand-alone distribution of node-based apps [1], I'm sure there will be many options (by the end of the year most likely)... Though, I'm not sure why you wouldn't take a more direct approach to building your code to different platform targets directly if you're using a compile language already... though if you're building web and want a standalone, I can see that.
But you only have to compile once for all platforms (famous last words, I know). Including future platforms, platforms you don't know about, and platforms you don't care about but your users do.
Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now.
Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?
WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer.
That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use.
wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)...
As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.
"In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1]
"Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2]
I figured this would be the case. This fact will contribute to lots of interesting discussions in the future regarding whether or not we should move away from JS and if so, how. Obviously having something like React is still hugely beneficial for reducing the logical complexity of creating UI, but you'd need to reconsider how you'd write your components without JSX or perhaps some language agnostic version of JSX would need to be created.. Or maybe we just implement E4X type syntax in other languages.
"Beyond the MVP" is the key phrase here. The first version of webassembly will not be able do that.
Just like it won't have dynamic linking, SIMD, shared memory (pthreads) or support for garbage collected languages.
It's worth noting that those features were already on the path to being added to it asm.js before webassembly was even being worked on. Most of them are still going to make it to asm.js first.
The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.
> Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.
You cant port the entire applet infrastructure since WASM is limited to the same API as Javascript. If WASM doesn't support multithreading, languages targetting WASM wont.
When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an extremely secure sandbox. It's under Chrome's Vulnerability Reward Program, you're welcome to look for payoffs ;-)
For all the complaining about it, I think I will actually be a little sad to see Javascript go. It wasn't perfect, but it had a powerful unifying effect on the Web Community when we could write, share and learn about our code in a higher-level scripting language that we could all read. (Even if there were some surprising little quirks that took a while to get used to.) Despite the stated intention from WASM - there is just something fundamental about AST trees - no matter how well you pretty-print them - that doesn't allow sharing and shared learning the same way. As a run-of-the-mill guy who makes my bread maintaining websites as much as greenfield-developing them, I feel like I'm in for a bit of a rough ride trying to decipher and debug binary/AST code compiled from Perl (or whatever). Guess I'll have to suck it up and learn to do it, though.
It seems like they "could" complement each other, but that's not a defining characteristic of WASM. WASM, as I understand it, essentially allows me to take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and compile an AST that can be interpreted by the engine on the client-side. Which is great for Python/Haskell/Perl developers that they no longer have to pay the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe they shouldn't have to contribute to JS. We can call that a good thing, but let's not pretend that doesn't marginalize JS (which - again!! - maybe it should). "But they still don't have access to the DOM" is not much of an impediment to that Perl dev, and means as your run-of-the-mill guy I now have to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it in 5 hours instead of 12, but I'm still reading binary/AST which does not seem like an awesome time) and the cruft from whatever Perl-WASM binding library they forked from Github. Again - I know this makes life better for that Perl dev, and maybe he/she deserves it. But unless I'm missing something, I don't see how allowing that dev to (basically) skip JS in their path from whatever IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it seems like now that dev will start making/contributing to libraries that conform to their stack (Perl-specific web libraries that compile to WASM). Now if I want to contribute to that library - which is now a part of the web - I have to learn Perl. Before, that Perl dev would have had to learn Javascript - which I know sucks for them - but it was good for me and good for Javascript... and I would say "good for the web". We were all speaking the same language, which led to an explosion of learning and collaboration. Sure, .3 != .1 + .2 But it was that way for all of us. Now everyone is going to go back to their own little feifdoms and just tipping their hat to JS along the way with a lightweight DOM binding port.
Yeah, the VM is the same but allows low-level JS instructions to run. So next step, is to build a <your favorite language> to webasm transpiler and not have to use JS again ... :) I believe emscriptem is already doing this for C/C++
You don't need any of those to make websites and web apps already (or to be less pednantic, you don't need most of those) so I'm not sure what your question is.
Furthermore d3, typescript and jquery is javascript so the question is more like "do I need to learn how to use tools to make websites?" at which point it is kind of silly.
They're being downvoted because show me useful website that doesn't have any of those things. Yes, it's technically correct to say that you don't need any of those things, but totally pedantic because you WILL use any number of them for ANY real website.
Most if not all use CSS and javascript, but he mentioned a ton of techniques in such a way as to imply that most websites use all of them or that you needed to know all of them to do web development.
That is just not true. I am sure that most web developers don't know d3, svg (other than exporting it from a drawing program) or typescript.
Think of all the technologies you have to learn to make Desktop or Mobile Apps, or both. You'll need a language to compile to Web Assembly. Then you'll need a target display layer: DOM, SVG-DOM or Canvas. DOM support for text and user interaction is way better than SVG or Canvas.
Yes, in the future you will be able to programm your Website in C++ and OpenGl (2.0) and export it to WebAssembler and WebGL, if you think this will be easier ...
edit: this might actually work for some people, once you can access dom elements directly, but for now it is meant for huge WebApps, like games in the browser
But he said it, like it might be easier for him, to avoid learning html and co in the first place ...
To which I would say, if you are allready a pro at designing UI-Elements in OpenGL and c++, then yeah, otherwise probably no.
If you're targetting HTML, you will likely need at least CSS... most JS is optional, and there are compile-to options.
That said, this should allow you to target a canvas element, with minimal JS binder to wasm code... all logic including what gets rendered could be outside JS... but you'd have to think of and control all input/output, and there are other considerations for rendering performance.
You are talking about a step in a specific direction.
If you make few more steps in that direction, you can simply write your own operating system, make native apps for it and then call it all "a website", because you can run it in a browser using e.g. this JS computer simulator https://copy.sh/v86/
You'll still need to learn CSS and SVG as they are web techs, but you wont have to learn anything related to Javascript anymore. As for now Javascript has become irrelevant for good.
WebAssembly doesn't intend to replace jQuery, D8, or CSS. However, we definitely plan to enable efficient DOM access. Doing so requires supporting some sort of native Garbage Collection, as well as the concept of opaque reference types. See more here: https://github.com/WebAssembly/design/blob/master/GC.md
Python is just another language VM. C Python should work just fine in WebAssembly, and bridging the APIs to the web (e.g. filesystem, etc) is already possible through Emscripten.
We don't plan to do things for WebAssembly, we plan to make WebAssembly powerful enough that anyone can run their language VM :-)
I think what they meant is that they could use python without having to also ship the implementation like CPython. I mean, that thing is huge. How is it feasible to serve 10mb for a website?
That's awesome and means alongside ObjectiveC, I effectively waited out deep diving on 2 (soon to be) formerly popular programming languages. I get to use my preferred language, Python, for even more.
The article specifically mentions first class DOM manipulation as one of the next goals. That's been part of the plan from the start. Maybe you're thinking of web workers?
Julia would still require the garbage collector but I don't think the downvotes here are fair at all. If there was a language that would be a natural transition to people used to javascript but wanting native speed, julia would be it. In a way it is a glimpse of what javascript could have been given a lot of experience and much more design.
You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: https://github.com/phoboslab/jsmpeg.
It is unlikely to ever compete battery-wise with hardware support for a codec, however.
Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support.
* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.
Are you guys taking a look at Intel's ISPC language? I haven't seen anything even come close as far as SIMD speed goes. It is open and compiles to LLVM -> .o + .h files.
I don't know, but I doubt it. Maybe there is knowledge transfer there, but ISPC is a separate language that uses a 'varying' keyword to control whether a variable represents a SIMD 'gang' or not.
Oh but it is; see also asm.js, which is a subset of JS that removes a lot of the potential performance bottlenecks by removing those features from JS (mostly having to do with JS' dynamic nature, iirc).
Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.
Unoptimized JS compared to unoptimized C compiled to wasm is likely to be slower, although if you only care about hitting 60fps, it doesn't matter if the unoptimized JS already hits that consistently.
If you care about GC pauses, wasm is much less likely to be affected.
Finally, if you compare asm.js to wasm, wasm will have a speedier load time, especially for large projects.
> It's literally the same compiler in V8.
AFAIK, V8 has bailouts for JS code, while wasm code cannot bail out. It uses the same compiler as when JS code gets JITted, but it is AOT.
Would there be any benefit to compiling dynamic languages with GCs (like Python or Ruby) to WASM? It is cool that is technically possible, but this looks like a target for C, C++, and Rust code.
It is more attractive to look at WASM as a way to bring a lot of other languages into the web. We are already transpiling a lot of code, ES7, TypeScript, ClojureScript, Dart, and so on. I would say WASM makes a lot better target than JS will ever be.
Does anyone who is familiar with WebAssembly development know what kinds of things Dynamic Linking (mentioned among the future features) will enable? For instance, would it permit the creation of optimized WebAssembly libraries written in C++ that could be called by a JavasSript program (say, for things like image processing)? Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser?
You can already do some of that without the dynamic linking feature. There is a JS API to instantiate a WebAssembly module, providing JS functions that are callable as external functions from within the WASM module. Conversely the WASM module exports functions that are callable directly from JS.
This allows rudimentary interop between JS and WASM, and dynamic linking will make it possible to deliver your WASM application in separate pieces, e.g. a large, rarely-changing library that is cached, precompiled, by the browser, and a small, often-changing application piece.
>>Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser?
The hard part there is the "eventually". They do state that the missing pieces will come some time after the
"Minimum Viable Product", but none of it sounds high priority.
- The current course omits features that would be needed for any dynamically typed language (including Python) to work. (garbage collectors, polymorphic inline cache, etc)
- The current course also prevents anything running in the WebAssembly space from accessing the DOM. You can call your WebAssembly from javascript, but that's it.
I suspect it will be quite a while before there's more available than "call LLVM created libraries from javascript". Technically, you could, I suppose put the entire cpython codebase into webassembly, but that seems like more of parlor trick than something useful.
This is going to be huge for the WebVR community. The demo actually ran great on my janky laptop, whereas the ASM.js version at a lower resolution ran at the considerably crappy level I had come to expect of Unity HTML5-built apps on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos should burn less battery power on my smartphone as well, which means less heat build up, which means a longer time before the GPU throttles down.
I can't help but to think that this could be a huge win for binary modules in node.js, as it could finally allow for cross-platform, prebuilt binary modules without the tight coupling and build dependencies that are currently needed.
The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now.
Question please: Even though there is stated desire to support python etc vm, this will be hampered by the need for the client to download the large VM vs native code that can be distributed itself, correct?
This is great news! And a nice working demo ...
And a general question about wasm - since typescript can be strictly typed, would it benefit much, if it would be compiled to wasm?
I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type.
So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all.
Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a lot of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.
I think I would be happy with the subset and the add of Integers ...
Dynamic languages are great for rapid prototyping and debugging, but once the programming is done and everything is clear, I don't realy need stuff like window["foo" + someString](1,2,3) or the "any" type anymore ... I don't think it will be too hard, to "strongtype" your ts or js if there will be such a subset and you have a smart IDE.
Ah right, the gc. I doubt you will see much benefit, if you will have to compile him as well.
But maybe it is possible to code without ... and free memory yourself with
"delete x"
or "x=null"
Oh man I'm very excited about this! Great job all around!
Web Assembly should make code more portable and faster on the web. No more transpiling to JavaScript (which honestly is a hack; going from one language to another language which is then compiled). If you want to use CoffeeScript, even though I dislike it, you'll be able to compile directly to WebAssembly instead.
I can't wait until this is fully baked with DOM access, etc.
Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.
> Transpiling some dynamic languages to JS is still sensible.
It's still practical, today, should you want to use something other than JS but I don't think it's that sensible. You take one language's syntax and idiosyncrasies, convert it to another language with its own, sometimes differing, idiosyncrasies and now you have to debug it, sometimes in a different language than it was written it.
I don't mind TypeScript or any of the others but I think WebAssembly is what makes those language great; transpiling to JavaScript is a hack.
Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly after announcement because your JavaScript now compiles to WebAssembly. You won't have to wait or deal with browsers that are lacking the necessary APIs; it'll "just work" because it's all compiled to WebAssembly.
That's not what jfbastien is saying. The point is, until the time when WebAssembly has a GC and a JIT, many dynamic languages simply won't be able to target WebAssembly (unless the dynamic language developers create their own bespoke JIT/GC), so you may as well stick to targeting JS.
At the point at which WebAssembly gets a JIT and GC, then the situation changes.
I know programmers sometimes write directly in assembly for certain performance enhancements and certain hardware access. Is there a foreseeable reason someone would program directly in WebAssembly though? I realize that's not the reason this technology exists, just curious.
When asm.js came out I ported http://wry.me/hacking/Turing-Drawings to use it. It would've made as much performance sense to do the same for WebAssembly. This is not quite the same as hand-coding WebAssembly -- it's making a custom code generator for a little language.
As far as I understands, this should be doable.
But it would probably be much easier to use another (static) language for the parts you want to optimize, compile to wasm and then access them in your js code.
Yes since it's lower level, and No since you'll still be limited to Web APIs like Javascript. The code isn't being executed outside the browser like a Java applet or Flash.
That three major browser teams implement and publish a new standard/technology at the same time is exciting. OTOH I can't believe we start over again with Assembler (a machine language).
Well, it runs on a virtual machine, not that much different. And the design doc states "writing by hand", but the s-expressions look interesting. Finally Lisp for browsers :)
Go has a GC that runs on top of an OS. The virtual machines that run WebAssembly are highly likely to have different mechanisms to manage memory compared to an OS that Go runs on, so Go's GC will not work 'out of the box'.
This leaves two options:
1. Go developers could write a GC especially designed to enable Go on WebAssembly.
2. Go developers could wait until WebAssembly gets its own GC implementation, and make use of that.
Considering option 2 is less work, and that a GC for WebAssembly is on the WebAssembly roadmap (check the GitHib page for details), I'd suggest option 2 is what will end up happening.
It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first-class platform for launch.
It's a little early, so things are not easy to use yet. Spec still changes, tools still change and break, nothing is optimized for convenience yet, etc. But here is how to use emscripten to emit WebAssembly currently,
https://blogs.windows.com/msedgedev/2016/03/15/previewing-we... https://v8project.blogspot.com/2016/03/experimental-support-... https://hacks.mozilla.org/2016/03/a-webassembly-milestone/
introducing support for the live demo:
https://webassembly.github.io/demo/