why not java or .net?

[kovalenko0]

Why not just run JVM or .net bytecode in browser?

In that case we could benefit from infrastructure of these platforms and already implemented interpreters

[krux02]

I am new to WebAssembly too. But I guess this has already been been asked several times. Maybe it should be in the FAQ.

My guess is that it is because .net and jvm are not only bytecode, they are a virtual machine with their own garbage collection and class loader and reflection. WebAssembly is really just about low level operations platform independent in the browser. I think you could run a JVM in WebAssembly, but that would not give a result you would want to have. It would simply add the startup time of WebAssembly and the startuptime of the JVM. And you would have two different garbage collected heaps. The one from JavaScript, and the one from your new JVM. I think currently you are better with GWT.

[RyanLamansky]

It's more accurate to think of Web Assembly as an evolution of asm.js, rather than a completely new technology. The only capability it really has over asm.js is 64-bit integers, which aren't even needed for most programs. This limited scope allows it to be integrated with relative ease into existing JavaScript engines.

One of the veterans from the Web Assembly project will probably have a more complete answer, and I agree this would be a good FAQ item as this is likely to come up often when 1.0 ships.

[topokel]

Jvm and .Net bytecodes are specialized for their relevant virtual machines, each of which have their own concerns and problem spaces they're trying to solve separate of the virtual machines ran in web browsers. Adapting an entire second virtual machine to run on web browsers would be cumbersome for users, and adapting Jvm and .Net vm apis to run within existing virtual machines would be implementationally cumbersome, and inevitably cumbersome for users, and possibly more error/bug prone as complexity grows. Web Assembly is designed as a simpler ISA that can easily be ran in the existing Javascript virtual machines already in browsers, with a focus on optimizing transport-time and load-time, a set of requirements existing bytecodes don't fulfill adequately.

[jfbastien]

I was sure we had something about this in the FAQ or Rationale documents. We don't. It would be a great addition.

@kovalenko0 If I can offer my opinion. JVM and .net did not do well on the web because they would have added a significant attack surface and thus a significant burden and also bloat. If in future they could run within the wasm sandbox then that would add a layer of protection that might mitigate the burden. Wasm for now seems focused on a low level language close to the hardware, and hopefully a much smaller attack surface for it's sandbox, and hopefully a good target for code in general. There have been some other very significant attempts at low level languages, such as NaCL but in my opinion that failed because it was too low-level deploying cooked native code that required validated. Wasm is hopefully just a little higher level with a translation layer that gives a little more flexibility and allows retargeting to any processor and also opens the way for more general validation and baking in those validation deductions into optimized code.

@kovalenko0 Oh, and getting all the web browser vendors to agree to bundle a JVM and .net might have also been too much of a barrier (I expected for reasons such as the attack surface and bloat but perhaps for much more petty reasons too), so asm.js worked with what was common ground. Wasm might allow people to use JVM or .Net on the web even without agreement between the web browser vendors, and for people to make their own judgements on the security and bloat.

[RyanLamansky]

I'm willing to write up an addition to the FAQ by combining the answers here, but what's the contribution process for this project?

[titzer]

Make sure you've joined the community group, and then submit a PR to the design repo.

…

On Fri, Jan 27, 2017 at 7:56 PM, Ryan Lamansky ***@***.***> wrote: I'm willing to write up an addition to the FAQ by combining the answers here, but what's the contribution process for this project? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#960 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALnq1BziU5qIZOBNq5fBYLfOjoeOkMIzks5rWj3SgaJpZM4LmzIH> .

[jfbastien]

Contributing details. They're linked to from the "new PR" page 😁

[RyanLamansky]

I was initially planning to add a section below LLVM, but seeing as that section was written in 2015, some parts of it are outdated. For example...

We believe that by taking our experience with LLVM and designing an IR and binary encoding for our goals and requirements, we can do much better than adapting a system designed for other purposes.

...seems far too cautious given that the current WASM binary encoding is working flawlessly in browser previews.

I'm now considering replacing the LLVM section with a more general discussion about existing byte codes (mentioning LLVM, Java, and .NET as examples), worded with much higher confidence in the approach taken by the WebAssembly team.

Any objections?

[jfbastien]

@Kardax what to do with the LLVM section would be up to @dschuff / @sunfishcode.

@Kardax Perhaps it's better to not add anything because there are a lot of pros and cons in different designs and still a lot of improvements that could be made to wasm. Asm.js might have been 'working flawlessly' from your perspective, and in some ways had better performance than wasm, so there is more to it. You might want to explore the parsing/decoding and compilation times and performance.

[RyanLamansky]

@Wllang ...what are you talking about? I never said ASM.JS had better performance than WASM. I think you completely misinterpreted what I wrote. I also strongly disagree that there are lot of improvements to make to WASM's current binary encoding for MVP; I'd say it's about 98% good to go as-is, and I could live without the last 2%.

@dschuff / @sunfishcode Is the lengthy discussion of LLVM bitcode still relevant? I think the viability of a specialized binary encoding has been thoroughly proven, so we could kill three birds with one stone by addressing LLVM, Java, and .NET intermediate formats in a single section.

@Kardax Sorry, did not intend to imply you 'said ASM.JS had better performance than WASM'. But for example Asm.js has constant module variables and these can be baked into compiled code and that is something that wasm does not have and that was very useful and get a similar feature in wasm requires user code to rewrite the module.

How could a group objectively assess a claim that wasm is within 2% of 'good to go' (whatever that means) Do we know what the best possible performance is, the best encoded size, the best decode and compile speed etc, the lowest decode-compile resource usage etc? We don't want to make it personal, not that someone knows best, and even responding to such a claim is very difficult, we need to talk about technical ideas that can be assessed on technical merit.

The FAQ llvm discussion looks valuable to me, lots of good points, and still very relevant and personally I am still exploring the design space and find such rationale very useful.

We still do not have really high performance decode and compile implementations and I expect these will really help finalize the design decisions and I see that the design is could go in a number of different directions. The encoding still has very incomplete definition-last-use information (the stack popping gives some of these) which is needed for register allocation and I expect the live set is needed to implement spill algorithms, and their might be more that can be done with loops, etc. There are a lot of other issues too: the deployment pipeline, and integration with web browser objects which could flip the design in very significant ways.

[sunfishcode]

@Kardax Yes, the discussion of LLVM IR is still relevant, for at least some audiences.

As an aside, you mention "viability" and "working flawlessly", but I'd suggest that at this level, those are essentially taken for granted. Many kinds of things could have been made to work; the question is, why was one chosen instead of others?