Will there be a JS -> WASM compiler?

[bguiz]

After scrutinizing the design docs, I was able to find a mention of a polyfill that would transpile WASM -> JS. I was also able to find mention of a C++ -> WASM compiler.

However, I was unable to find any mention of a JS -> WASM compiler.

The majority web developers are fluent in Javascript, and thus a JS -> WASM compiler would be ideal. Web developers will want to continue writing their websites using Javascript, instead of writing them using C++. Thus I am not sure what to make of the MVP, nor the post-MVP sections making no mention of a JS -> WASM compiler. What is happening here?

[creationix]

Browsers will still have native JavaScript VM along-side wasm. There is no reason to compile JS to wasm because you would have to also include a whole javascript vm. The resulting code would be huge and slower than the JS VM natively provided.

There is a task post MVP for adding things like adding access to the GC from wasm code so that scripting languages can be implemented for wasm.

[jfbastien]

JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm! I mentioned this recently and @BrendanEich accused me of having been taken over by horse_js.

To be clear, wasm's goal isn't to replace JavaScript, it's to supplement it. It's therefore not really a goal at the moment to support JS → wasm, but the features we want to implement will make it possible. I'm not sure it'll be that useful from a developer's perspective, though. You may get some size reduction, but that's about it. From a browser's perspective it may be interesting to have the JS engine implemented in wasm from a pure security perspective.

[creationix]

@jfbastien I beat you by 2 seconds ;)

But your answer is better. I'm excited for GC and JIT in wasm. I love creating my own languages and running them on the web.

[bguiz]

And how about supporting variants such as asm.js or TypeScript/ES7? These flavours of Javascript promise some level of type guarantees.

I'd imagine the need for JIT would be less so, but GC still very much needed for these languages. Would having a {typed flavour JS} -> WASM make this any more feasible?

W: http://bguiz.com

On 24 June 2015 at 09:44, Tim Caswell notifications@github.com wrote:

@jfbastien https://github.com/jfbastien you beat me by 2 seconds :P

— Reply to this email directly or view it on GitHub https://github.com/WebAssembly/design/issues/219#issuecomment-114675456.

[titzer]

Yes, an asm.js -> wasm translator is a high priority, and Luke already did work on a compressor that might serve as a good starting point.

On Wed, Jun 24, 2015 at 1:59 AM, Brendan Graetz notifications@github.com wrote:

And how about supporting variants such as asm.js or TypeScript/ES7? These flavours of Javascript promise some level of type guarantees.

I'd imagine the need for JIT would be less so, but GC still very much needed for these languages. Would having a {typed flavour JS} -> WASM make this any more feasible?

W: http://bguiz.com

On 24 June 2015 at 09:44, Tim Caswell notifications@github.com wrote:

@jfbastien https://github.com/jfbastien you beat me by 2 seconds :P

— Reply to this email directly or view it on GitHub <https://github.com/WebAssembly/design/issues/219#issuecomment-114675456 .

— Reply to this email directly or view it on GitHub https://github.com/WebAssembly/design/issues/219#issuecomment-114677789.

[MikeHolman]

We have spoken with the TypeScript team about this possibility and they have shown interest, but it seems like progress there is currently gated on adding typed objects into JS.

[BrendanEich]

@bguiz: JS engine is the wasm engine, and it will continue to support the evolving JS standard language. No worries there (I wasn't sure whether you thought that might go away. Not in any future that I can foresee). OTOH as others note, wasm needs time to evolve GC, JIT support, and other dynamic language features, to be a first-class target for JS. Even when it does evolve these things, I have doubts that JS/wasm engines will drop their JS syntax and built-ins in favor of downloaded JS-in-wasm VMs. We shall see!

/be

[sunfishcode]

An asm.js-to-WebAssembly translator will also be something we're planning to add to Emscripten.

As for regular JS, I think others have answered the question above.

[alexino2]

The whole point of JS is easy to code and can do amazing things : dhteumeuleu or codepen.io/ge1doot, but you can see the source and it's easy to hack.

"wasm" is only a way to sell more game and others apps for google, apple an co. The only "evolution" is that there'll be able to control you better with "no install", directly from the big brother server... I'm just surprised they are not afraid of eating each other yet...

[gregtour]

It's possible with code analysis or code annotations to compile ECMAScript to WebAssembly. This doesn't sound like a priority for the WebAssembly team but it does sound like a great idea for an independent effort.

[evanw]

I just started experimenting with a toy programming language that might be relevant: https://github.com/evanw/thinscript. It uses TypeScript-style syntax and compiles to WebAssembly. I figured I should mention it because it might be an interesting case study. Also I was pleasantly surprised by how easy WebAssembly was to generate. Nice work everyone!

[sunfishcode]

I would caution people about using very thin wrappers on top of wasm though, in general. As one example, thumbing through the thinscript code, I see there's a while statement which is lowered to loop { if (!condition) break; }, which will be less efficient than if (condition) loop { ...; br_if condition } on several wasm engines.

To me, the thing that makes wasm more than just a reheated JS is the possibility of a different philosophy: because wasm is a compiler target, compilers can perform optimizations before shipping the code to clients, so we can keep client-side VMs simpler and faster. However, if thin wrappers around wasm become popular, there's a risk that client-side implementations will eventually have to grow bulkier and more complex in order to do the optimizations that aren't being done.

[evanw]

Yes I agree. One of the things I like most about WebAssembly is its simplicity. I'm planning on adding compiler optimizations and doing benchmarks once the language is more complete. I expect inlining to be one of the bigger wins, for example, and I wouldn't expect WebAssembly to do that for me. I'm also planning on experimenting with a machine code target and I will be using the same optimizations for both targets.

[sunfishcode]

Sounds very cool! I'll be interested to see where it leads.

[affixalex]

I'm imagining JS->WASM being more appealing for servers than clients. As a very high-level overview of the architecture that I have in mind...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

In this conception, a clear mapping from WASM to LLVM IR for garbage collection would be very desirable. Promotion from IEEE doubles to integers could be done as an LLVM pass. The notion of separate JITs for warm and hot code could be implemented in terms of LLVM pass managers.

Just some thoughts, please feel free to delete this if it's spurious!

[AlicanC]

Cross environment compatibility is a serious problem in JS ecosystem. Babel tries solves this problem by transpiling down to some more adopted version of ES and I guess we can all say that it is pretty successful.

There is still an issue here though. For example, if you are transpiling your ES 2016 code down to ES5 for compatibility and your code happens to run on an environment with (partial or complete) ES 2016 support, you will be missing out the benefits of having ES 2016 support in your environment.

If everyone is transpiling their code down to ES5, then what is the benefit of having ES 2016 support in an environment in the first place?

A new project called "babel-preset-env" tries to fight this issue by targeting environments by their versions. The idea behind it is that (1) you ask it to target specific versions or "latest X versions" of browsers, (2) it determines the lowest common denominator of features and (3) enables only necessary transpilations. This helps, but sadly can't solve the issue.

We still have the risk of a major vendor not behaving and causing the same issues Microsoft was causing with Internet Explorer for years. The whole ecosystem is in hands of a few vendors, who decide what to implement and when to implement. This is not free nor open.

The only solution is a new compile target for JavaScript which is performant and needs a lot less maintenance (hopefully none) than a JS engine. When environments (browsers, Node.js, etc.) starts supporting such a target, implementing new ES features should become the responsibility of compilers and not engine vendors.

[Simran-B]

JS -> WASM would be interesting to protect intellectual property by code obfuscation when it comes to on-premise installations of let's say Electron apps on customer servers. It's hard to believe but true, there are many small institutions in Germany with very little or no internet connection, which requires on-premise installations, but giving your entire code in plaintext to them can be scary for software companies.

[ghost]

@Simran-B Wasm has as a design principle to support a familiar text format. Notably it has a structured control flow design for quick analysis, and is optimized for single use definitions used in stack order so optimized for readable expressions. Thus it is not a 'code obfuscation' target, but developers can emit their own 'code obfuscation' on top of this but should understand that this is expected to have a cost in terms of decreased encoding efficiency and decreased performance.

[Richard87]

Hi all, I just resently discovered WebAssembly, but thinking about the JS -> wasm compiler, I imagined something like Angular2's Ahead-of-Time compilation, jsut way more optimized (I'm thinking machinecode instead of javascript)... Will this ever be possible? Is it worth it?

EDIT I'm also thinking, is will there ever be a possibility for the browser to send a flag to the client that it supports wasm, and then we can serve up a precompiled app instead of a javascript file?

Richard

[distransient]

@Richard87 you could think of webassembly as a platform independent instruction set with its own specialized encoding and calling conventions. There's nothing saying you can't describe a subset of javascript that'd be very easy to transpile to work in webassembly's world of those things, but enforcing that would probably be difficult. The featureset and implementation surface area are forever growing in javascript, and adapting existing libraries and frameworks to work in that subset would likely be difficult, especially given the current lack of garbage collection in webassembly, and you'd essentially lose the benefits of existing javascript code.

With the addition of garbage collection primitives in webassembly, the subset of javascript that would be feasible to transpile without writing a big ol' virtual machine would widen, but it still in my opinion wouldn't be optimal compared to just transpiling from a more suitable language, since your overheads in javascript would only be marginally smaller, the important overheads in web applications (the network!) would widen, and the benefits you'd want to reap from using javascript in the first place would still be out of reach, besides getting to say that it uses something that resembles "javascript" (this is actually a similar boat that Unity is in with UnityScript, except they adapted it somewhat to integrate better with their subsystems and calling conventions in general, besides other whims).

[metacritical]

I think it is extremely important for some of us who are looking at Browser and Webgl to be faster for gaming. I intent to bring a commercial quality game in webgl but the current tech produces so much garbage that frames skip. Browser gaming using JS game engines has almost failed and Unity took off. I think C++ => Wasm is an undue advantage for these big Unity like framework makers who could cross compile their code to WASM. But what about people who write JS by hand using Three JS or Babylon.. Not having a JS/Asm.js => Wasm toolchain would mean large application in Js would be dead and people would use C++ and code generation backends to produce Wasm. More specifically in games and such. Not having a JS => Wasm backend in unfair to JS Developers. Also EMCC allocates a Big heap when it runs and speeds are evident due to that, but Js Developers who write good js Code still couldnt achieve so much performance due to the complexity of writing such code. There should be some mechanism to reuse most stuff and ability to call gc earlier or at will. Frame skipping when the GC runs causes Webgl to skip frames is a big problem and needs to be resolved. There should be some mechanism to hand tune JS code better than Code generators. like hand written Assembly still produces much smaller and highly aligned code. That should be possible in web-assembly.

[RyanLamansky]

@metacritical C++ can compile to WASM because many people put a lot of work into the process. The same could happen for JavaScript, but as far as I know, no one is attempting this currently. There is little reason to do so: performance will be unchanged.

Your engine's problem is garbage collection. This problem doesn't go away if you build a garbage collection algorithm that uses linear memory and WASM code... eventually you have to stop the program to see which objects are still alive and delete the ones that are not. The solution is to not create garbage objects, preventing the need for the GC to ever run. You don't need WASM to achieve this, you need to rework your engine.

[metacritical]

Ultra pristine Javascript that reuse Arrays and produce low garbage are extremely hard to write. Also i think Plain Js cannot be compiled to WASM. Asm.js or Typescript would be easier to compile to WASM due to availability of type annotations or types in them respectively.

[RyanLamansky]

@metacritical Difficult, but not impossible. Even in the C++ engines, much of the code is around object lifetime management. Although unconventional, there's no reason you can't do the same in JavaScript.

Plain JS could be compiled to WASM but the compiler would have to add a lot of helper code to enable JavaScript's higher-level features like garbage collection, reflection, properties, and so on. Basically, all the stuff you get for free with the browser's built-in JS engine. TypeScript doesn't help much.

By comparison, ASM.JS would be easy to convert to WASM. The strict subset of JS features allowed by ASM.JS is also 100% covered by WASM. If there were a large volume of code written in ASM.JS, this would be a worthwhile effort, but as far as I know all the major ASM.JS files are produced from C++ source code, which can already directly target WASM.

[kripken]

By comparison, ASM.JS would be easy to convert to WASM.

Correct, and actually the main way we compile C++ to wasm today is to compile it to asm.js first, then compile that asm.js to wasm using Binaryen's asm2wasm.

[metacritical]

@kripken Looking at the asm.js specs it seems easy to write handwritten asm.js, which means all is not lost for js programmers, we can still get WASM binaries using the above.

[aruns07]

Wouldn't evolution of JS i.e. strictly typed language, could make it a good candidate for JS -> WASM? I think TC39 has proposal for typed object. May be more other features could make it possible.

[RyanLamansky]

@aruns07 The fewer JavaScript features you allow people to use, the easier it would be to compile to WASM, and the more likely people will be unwilling to live with your restrictions due to incompatibility with their favorite libraries.

[metacritical]

@Kardax @aruns07 People love the convenience of a Dynamic Language. We need strong types occasionally not all the time.

[Mohsen7s]

jfbastien commented on Jun 24, 2015 JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm!

According to following link : https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html WebAssembly consensus and end of Browser Preview

Now, 2 years after your first reply, WebAssembly is now supported by major web browsers today. So it's not equivalent to implement JS engine in wasm. The advantages of js -> wasm is not only GC support, but also smaller code size, and faster execution, specially in the field of Hybrid application development such as Ionic2 which usually produces a JS file around 10MB which cause application load time to exceed 5 seconds(each 2MB parse of JS = 1 second)

@jfbastien So please post your updated answer about JS -> wasm transpiler ?

[MichaReiser]

As part of my master thesis, I'm trying to write a Transpiler from a subset of JavaScript to WebAssembly. At first, it will be limited to TypeScript, but other typed variants like Flow might be supported in the future.

However, the goal is not to implement the full JavaScript language as, in this case, I would face the same issues the JIT implementations face today, and therefore, no speedup can be expected (more certainly, my implementation would be 100 times slower!). It's going to be a subset like defined by SoundScript

My goal is more to allow specific parts of an application to be compiled to WebAssembly without the need that the developer leaves his familiar developing environment or uses another programming language. Therefore, it will be more intended to speed up performance crucial parts of an application and not as a general purpose transpiler that accepts any existing JavaScript application.

I'm quite curious what my findings are going to be as I see the pros and cons of such an approach. Let me know if you have any input.

[jfbastien]

@Mohsen7s my answer remains accurate: the MVP version of WebAssembly doesn't support GC and JIT capabilities which make it possible to implement a fast JavaScript virtual machine. An interpreter is entirely possible, with clever tricks it can be quite good, but not as much as what native implementations do.

This is inherent to our "Minimal Viable Product" approach: ship something that works for some usecases first, and then add feature to meet other usecases. Please see the following thread for a similar discussion on MVP and missing "future features": https://github.com/WebAssembly/design/issues/992#issuecomment-281735235

[BossLevel]

Leaving aside technical discussions as to what can and can't be implemented currently, I'm amazed that JS -> WASM isn't the number 1 goal both philosphically and from a marketing perspective - I fail to see how you'll ever get developer buy-in until this is the case. If all those front/back-end/full-stack developers out there with JS skills capable of working in any market vertical wanted to instead spend their time learning C++ which is used in a substantially smaller subset of industries, then they would already have done so - I know, I speak as one. I can't help but feel that this whole discussion is a bit of an echo chamber and that those defending the lack of a compiler would find their time would be better spent speaking to people on the coal-face asking them what they really want.

[jfbastien]

@BossLevel

Leaving aside technical discussions as to what can and can't be implemented currently, I'm amazed that JS -> WASM isn't the number 1 goal both philosphically and from a marketing perspective - I fail to see how you'll ever get developer buy-in until this is the case. If all those front/back-end/full-stack developers out there with JS skills capable of working in any market vertical wanted to instead spend their time learning C++ which is used in a substantially smaller subset of industries, then they would already have done so - I know, I speak as one.

Browsers can already run JavaScript efficiently. Browsers cannot run the intended use cases as efficiently. To top it off, WebAssembly has non-Web aspirations.

This discussion, as well as https://github.com/WebAssembly/design/issues/992#issuecomment-281735235, illustrate the variety of goals different people have. None are wrong! MVP simply needs to prioritize who gets served first.

I can't help but feel that this whole discussion is a bit of an echo chamber and that those defending the lack of a compiler would find their time would be better spent speaking to people on the coal-face asking them what they really want.

That was the entire point of forming a W3C Community Group. We think it's succeeded, as we've heard from many interested developers. Some aren't interested in MVP, but are interested in future features.

[BossLevel]

@jfbastien

Browsers can already run JavaScript efficiently.

Ha, I've been trying to write a massively multiplayer HTML5 game capable of running at a decent FPS on an average mobile phone since 2008 and I'm still not there! And given that when I go contracting to pay the bills, I am extremely well rewarded, I'm pretty certain that my lack of progress is not due to the quality of my code.

That was the entire point of forming a W3C Community Group

Ha again - how many real world devs do you know that join a Community Group? The devs that do are typically evangelists etc who are knowledgable yes, but have felt less of the pain of real-life dev.

And I'm sorry, I really don't want to belittle anyone on this page/involved/at W3C. As you say, this is a discussion, and this is my point of view from the front-lines.

[BossLevel]

Apologies for coming back to this like a dog worrying a bone but whilst away I thought of a better way of making my point. In your next newsletter/community event or whatever means you have of garnering feedback, put this question to web developers (your customers):

In order to take browser-based performance to the next level you will need to learn another language; would this be acceptable?

Because that is basically the question that has already (to my mind, deleteriously) been answered by some on this page.

And finally (I promise ;-) ) @jfbastien, if:

To top it off, WebAssembly has non-Web aspirations.

why's it called "WebAssembly"?

[jfbastien]

@BossLevel I think I see where you're coming from. I can't speak for people doing the evangelizing, but my understanding is that different evangelists have been in contact with traditional "native" developers who are interested in WebAssembly. From your point of view that may not be apparent, but at a minimum I can point at Unity's interest as a sign of "serious" developers. These folks also post to github, under their own names, but affiliations aren't always apparent. It is not my place to speak for them.

Ha, I've been trying to write a massively multiplayer HTML5 game capable of running at a decent FPS on an average mobile phone since 2008 and I'm still not there! And given that when I go contracting to pay the bills, I am extremely well rewarded, I'm pretty certain that my lack of progress is not due to the quality of my code.

I didn't mean to imply that writing fast JavaScript is easy. What I wanted to say is: WebAssembly doesn't make optimizing JavaScript any easier. Rather, it allows browsers to consume a format which is better suited at generating reliable performance. It also allows TC39 to focus on improving JavaScript itself, not just JavaScript as a compilation target.

Ha again - how many real world devs do you know that join a Community Group? The devs that do are typically evangelists etc who are knowledgable yes, but have felt less of the pain of real-life dev.

And I'm sorry, I really don't want to belittle anyone on this page/involved/at W3C. As you say, this is a discussion, and this is my point of view from the front-lines.

Your point of view is indeed valid, and I think it's clear that from where you stand I'm saying something that's hard to believe. We should communicate this better (or hey, maybe I'm wrong :wink:).

In order to take browser-based performance to the next level you will need to learn another language; would this be acceptable?

Because that is basically the question that has already (to my mind, deleteriously) been answered by some on this page.

I see your concern, but I hope it isn't one that will turn out to be true. Again, I may be wrong. The way I see it, WebAssembly brings new developers to this platform, developers who had bad experiences with the Web in the past or heard horror stories. In turn, it helps JavaScript developers who want to use "traditional" code (what some call "legacy") use that code: we want WebAssembly to be easily usable from JavaScript. To achieve this it needs to be as easy as using npm (which... isn't always easy!).

I'm somewhat confident this will turn out because of the feedback we've been seeing on Twitter, Hacker News, Reddit, and various conferences. Again, maybe I'm wrong and I'm listening to echo chambers. At a minimum, I've had very promising discussions at conferences with people with C++ as well as JavaScript backgrounds.

At the same time, TC39 is truly trying to improve JavaScript. I believe it has in recent years, especially with ES6.

But your point remains: maybe developers will want to be well-versed in JavaScript as well as more "WebAssembly-friendly" languages such as C++ or Rust. I don't know which way things will go.

why's it called "WebAssembly"?

Ha! That's a wonderful question. I have a talk entitled "WebAssembly: neither Web nor Assembly". I'll have to give it publicly so I can express how I feel about the name :grin:

So I'll keep you hanging on that one.

[RyanLamansky]

I'm reading two desires here:

1. A binary representation of standard JavaScript for fast load times.
2. Something to bridge the performance gap between natively-compiled C++ and standard JavaScript.

Item 2 is the subject of ongoing research and massive investments by many companies. If you look at performance measurements of JavaScript engines over the past 15 years, it's working too... the gap is getting smaller.

Item 1 is not being worked on by anyone, as far as I know. It's massively complicated, and getting harder as JavaScript continues to evolve at a rapid pace. WebAssembly is very strict and relatively uncomplicated, and it still took years to develop.

[BossLevel]

@jfbastien - many thanks for your considered and considerate response :)

So a couple of illustrative points, in no particular order:

1) A good example I see of this entire discussion and my view on the direction you should be heading, lies with NodeJS - a JS API/front-end to a C++ back-end - you get the ease of use/familiarity etc on the one hand and the speed on the other. 2) Sticking with Node, back in 2008 when I embarked on my own personal odyssey ;-) I originally looked at both PHP and Java for the back-end (I was coming back to development after a decade on the dark side of IT management and sales ;-) !) but quickly discounted them for the simple reason that I only wanted to have to learn one language, and to learn that one well! A personal tale I know, but I doubt I am the only developer who feels this way, particularly those working for themselves, not on a company dime whilst they learn the language. 3) I deliberately haven't googled the numbers before making my next point (indeed I am unsure if I even could) but I'll be willing to bet that take-up of ASM was low. I know I got very excited when I saw the initial demo but upon learning that there was no compiler I immediately dismissed it. To ask a web developer who's part of the largest dev community on the planet (JS) with a vast array of APIs, libraries, resources, tutorials, frameworks etc available online to step away from that, is to my mind asking too much, and by not providing them with a means to potentially make that first step (i.e. a compiler) is missing an obvious trick on your part. I'd even go so far as to wager that development in Shading langage (GLSL) has seen more growth than ASM now that you can a) write it directly into excellent frameworks like Pixi.js and Three.js and b) play with it directly on sites such as ShaderToy. 4) The games industry/gaming generally. I can speak from experience here as a) I've been writing (as yet unreleased!) games for the past 9 years and b) I served on the board of TIGA (the trade association for the UK's game developers) for 2 years. Trust me, I think the number of game developers who wanted to migrate to the web could probably be counted on one hand - game developers are already in the industry they love and even taking a pay-hit/working long hours despite that, so these should not be WA's target audience. Yes, their employers are always looking for new mediums to port their games to, but let's not kid ourselves, excluding mobile (where native code sadly wins hands-down and which is what I want WASM to fix), web is still very much the poor relation to PC/console both in terms of performance and monetisation. 5) Conversely, whilst the bedroom coder/indie scene is not at the zenith it was a few years ago, there are a vast number of web developers who fancy making a web game in their spare time. And whilst I don't want to veer overtly into politics and I am in no way knocking the Unity guys (I've had dealings with a number of them and it's a great product), personally I think you should be looking after the interests of the multiple little guys, not the one big-guy (it makes both philosphical and commercial sense).

I shall very much look forward to seeing your talk @jfbastien :)

@RyanLamansky - I think you make a reasonable distinction. With respect to:

Item 1 is not being worked on by anyone, as far as I know. It's massively complicated, and getting harder as JavaScript continues to evolve at a rapid pace.

On an entirely personal level, as someone who's been writing JS 8 hours a day since 2008, I'd very much like to see the evolution of JS just stop for a while and let everyone else catch up! I've always worked on a principle of developing for the lowest common denominator i.e. if it doesn't have 100% support it's not happening (IE6/7/8/9 aside ;-) ). And so we find ourselves in the ludicrous position of focusing on trendy ES6 patterns and supposed use-cases when we haven't even got 100% browser support for ES5 across desktop and mobile. The language clearly works as-is (despite it's admitted foibles) as demonstrated by it's market-share, so how about we, as a community of developers, spend the next few years learning to write efficient, optimal code with what we have rather than yet again re-inventing the wheel with new hipster code (sorry I'm getting into rant territory ;-) )?

I think it's probably time I got my coat ;-)

[jvanderberg]

@RyanLamansky I have encountered the impression that WebAssembly will just be a new target for your bundle build process, and suddenly everything will be faster. Clearly that's not the case. WebAssembly has a very specific target use case, and likely won't have much to offer the typical web developer with a large JS code base full of business logic.

But as you note there are some gaps in the JS based development life cycle for more typical business oriented web applications: 1) Large JS bundles have a significant parsing overhead and typically provide insufficient obfuscation. 2) Standard JS code lacks the type annotations (and perhaps other hints) required to make JIT/Native code optimizations.

This suggest a possible solution is a properly typed and annotated version of JS that gives the developer more deterministic and transparent optimization paths, and a pre-parsed binary version of that version of the language.

[ganeshkbhat]

The comments and the docs say WASM runs besides JS and uses the same JS engine of browsers (optimized). https://developer.mozilla.org/en-US/docs/WebAssembly

I dont understand this question really.

Sorry to be asking a stupid question and making a stupid comment: Does the question and the Webassembly team's comment mean that Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? I see only subjective thoughts. Can someone explain this? If Webasembly is faster then Javascript then why not provide a transpiler? If Javascript is not possible then why not ES7/TS code? Why is there so much secrecy around this?

[RyanLamansky]

@ganeshkbhat The initial release of WASM is little more than a compact binary encoding of asm.js, which is a very strict subset of JavaScript. It does not run faster than asm.js unless 64-bit integers are used, as these have to be emulated in asm.js.

There are proposals to add features to WASM that would bring it closer to JavaScript in capability (garbage collection, DOM integration, threads), but there are no plans to add the full JavaScript feature set. So, it's likely a JS->WASM transpiler will never exist. Instead, new applications and libraries will be made that are designed to work within WASM's limitations. Today, that's C and C++, where the language restrictions align well with WASM and asm.js.

[rossberg]

There is no secret nor any magic. Wasm is "faster than JavaScript" because it is a much simpler language that is much closer to hardware. JavaScript is a complicated language that has to do many expensive things during execution. It wouldn't magically get faster by compiling it to native code through Wasm instead of directly.

[smvv]

@ganeshkbhat currently, it is not possible to allocate objects inside asm.js / webassembly. In asm.js and webassembly, all JavaScript operations will use one big typedarray to store and load there values. Creating JavaScript objects (e.g. var obj = {a: 1, b: 'test'}) and arrays (e.g. var a = [];) is not possible inside webassembly since there is no object support yet. This is a design decision of the Minimal Viable Product made to get webassembly support in all major browsers as soon as possible.

In a future version, GC support is planned for webassembly. We (LeaningTech.com developers) are working on a proposal for object support in webassembly, but that will take some time to land as a specification and an implementation in all major browser. Until then, it is not possible to transpile JavaScript (and CoffeeScript, TypeScript, etc.) to webassembly. When the proposal is accepted, it should be possible to transpile a larger subset of JavaScript, but it will not support all features that are currently available.

[ganeshkbhat]

Sure. Do look forward for better support for JS here. I definitely feel it can be supported. Writing a transpiler is what might be needed for type supporting languages.

[mauron85]

From what I read about webassembly, it is targeting mainly web browsers and in that area it doesn't sound very appealing to have js -> webassembly compiler. But I can imagine running webassembly in non browser environments. This is not entirely true as in can also run in nodejs, but I see it's true potential in nodejs environments in something like vertx - polyglot allowing running modules written in any language, that can be compiled to webassembly. I can imagine, that it will extremely difficult to get something like this done. It will require many features like GC, maybe even some kind of VM to be implemented, but nothing is impossible. Remember that many people were skeptical about asm.js too and look at it today.

For all those, that are excited (as me) about compiling js -> webassembly, there might be indirect and very bumpy way through js -> c -> webassembly using project ts2c transpiler in the future.

[RyanLamansky]

@mauron85 Non-browser and non-JavaScript runtime environments are definitely a consideration of the design, it's just that only the JS API exists today.

For my part, I've been experimenting with a .NET JIT system and don't see any real barriers other than time, and I'm sure there are others looking to integrate WASM into their favorite platforms, too. I'm certain a few years from now there will be high-quality non-JavaScript runtimes for WebAssembly, the only open question is the degree to which they'll be formally endorsed by the WebAssembly team.

[kabirbaidhya]

IMO one benefit of JavaScript -> WebAssembly compilation ability is that the developers/maintainers of the Javascript libraries and tools would probably be able to release their APIs in two formats:

1. in JS (as is right now) which users can use for browsers & node
2. WASM as the compiled library which might be more efficient.

And this is without having to ever rewrite their existing JS code in C/C++, if they want to unleash the performance benefits of WASM in their JS libraries. So the library developers would still be able to develop and maintain in Javascript and produce two outputs for two different targets both in JS & WASM.

And using the compiled WASM version library would definitely be more efficient for the users as all they need to do is to use the exposed API from the library and they obviously won't care whether it's written in WASM or not. But the performance would certainly be improved.

[distransient]

WASM as the compiled library which might be more efficient

Why? Why would a blob of javascript transpiled web assembly (worst case scenario, including much of the runtime for a javascript engine in that binary; best case scenario, including a layer built on top of the future builtin wasm GC, which incurs its own overhead anyways) run faster than that javascript thrown at a jit dedicated to... running javascript?

[kabirbaidhya]

Okay, you mean that would be even more slower with more overhead?

Perhaps there's something I haven't understood well. How is C/C++/Rust -> WebAssembly compiled stuff really efficient and even if there is a JS -> WASM support in the future that would cause overhead? Is that just because JS is a dynamic language and C, C++, & Rust aren't? Or is it because JS is by nature not a fully-compiled language but these other languages are?