Experimental support for WebAssembly in V8
v8project.blogspot.com
v8project.blogspot.com
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:
Dream or Nightmare? :-)
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.
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.
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."
https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...
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.
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.
[1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...
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.
I suppose the extra restrictions of Typescript would help. At least if you add extra restrictions to make it easier to compile.
These are totally sensible. Look at: http://www.call-cc.org/
...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.
I'm not sure how much space just cutting out the GC will save?
I mean, it is if you compile it to wasm. It is definitely JIT compiled.
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 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.
Read this: https://github.com/WebAssembly/design/blob/master/GC.md GC, DOM access, etc. don't exist in WebAssembly code, yet.
https://github.com/WebAssembly/design/blob/master/FAQ.md#whi...
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].
[1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...
[2] https://github.com/WebAssembly/design/blob/master/GC.md
[3] https://developer.apple.com/library/mac/documentation/Cocoa/...
No one wants to do web development in C++ honestly, but they would like the performance.
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.
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.
All of the "just-in-time" optimizations can be done ahead of time. Which saves [that much run time x that many users] in computer time.
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.
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?
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.
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.
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).
Speed. Oh and memory - if I could optimize it so that all our vectors, matrices and logic code did only stack allocations I would be a happy camper.
Why don't you compile into native platforms?
Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.
AOT compiling highly dynamic languages gives you very little room for optimizations.
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.
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);
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.
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().
1. https://developers.google.com/v8/experiments#strong-mode
2. https://groups.google.com/forum/#!msg/strengthen-js/ojj3TDxb...
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.
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.
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.
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.
The only difference in this hypothetical is that the slower path would run faster.
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.
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.
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.
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.
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.
1. https://github.com/WebAssembly/design/blob/master/AstSemanti...
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.
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.
[1]: https://internals.rust-lang.org/t/need-help-with-emscripten-...
The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.
[1]: https://github.com/WebAssembly/design/blob/master/GC.md#gc--...
[0]: https://www.w3.org/community/webassembly/
[1]: https://github.com/WebAssembly/design/blob/master/TextFormat...
[2]: https://github.com/WebAssembly/design/blob/master/Tooling.md
We should make sure that browsers refuse to run any code in the future that isn’t available in its full source.
Yes, that includes ReCaptcha
/me looks angrily at Google
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.
View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
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.
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.
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.
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.
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 those optimizations are only for speed.
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.
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?
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.
It will according to multiple sources:
"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]
[1] http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md
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.
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.
Things missing are usually specific external protocols. e.g. being able to make a TCP socket; (or higher level things like ignoring CORS).
It probably won't be as fast though but for legacy Flash content that would be fine.
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.
No javascript needed to make a perfectly functional, efficient and useful website. Maybe it doesn't fit into your description of a "real" website?
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.
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
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.
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/
We don't plan to do things for WebAssembly, we plan to make WebAssembly powerful enough that anyone can run their language VM :-)
There has been work released recently which allows programs to be compiled to native binaries if they aren't dynamically evaluating anything however.
It is unlikely to ever compete battery-wise with hardware support for a codec, however.
* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.
Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.
They're both just-in-time compiled. It doesn't matter if your program comes in as source code or a binary format if you're compiling it dynamically.
But I didn't know that WebAssembly ran under asm.js semantics. I guess that's the difference.
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.
It's used in production on Wikipedia: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/o...
More general-purpose GC will be supported, but not in the initial release: https://github.com/WebAssembly/design/blob/master/GC.md
Because that would pretty cool.
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.
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.
How is the mapping from wasm to asm done, at all?
Are they directly mapping from web world to native world in a sandbox ?
Does anyone know if theres a webassembly to js compiler to support legacy browsers?
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.
Also keep in mind that webasm doesn't include a garbage collector. If typescript relies on one, it will need to be compiled to webasm as well.
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.
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.
At the point at which WebAssembly gets a JIT and GC, then the situation changes.
And it's really intended as a compilation target; I don't think anyone wants or expects average web developers to code in wasm.
Might help them improve Google Docs a lot if they could utilize some mature C++ libraries from a desktop word processor.
Is anyone working on a Go to WebAssembly compiler yet?
I don't think that'll work until WebAssembly has GC, which isn't likely to be ready for a while.
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.
https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W...
(linked to the Github mirror because the LLVM viewvc is currently down)
I'm guessing you're a JS diehard that doesn't want to see other languages hit the web? I'm not aware of any other reasons why you'd fight this otherwise.