Re: WebAssembly and Bytecode question

Hi Rahman,

I think I see the confusion, so I'll try to clear it up. Hopefully, I don't
create any more confusion.

JavaScript, has traditionally been an interpreted language -- meaning that
the engine reads code directly. From the diagram above, this would have
looked like this:

Java Source ------> Java Source AST -------> Java ByteCode
JS Source

This might be easier to reason about if we add "interpreters" to the
diagram. Interpreters are the part of the code that reads code directly and
preforms actions based on it.

[Traditional Java]
Java Source ------> Java Source AST -------> Java ByteCode => Bytecode
Interpreter

[Traditional JavaScript]
JS Source => JS Interpreter

When google introduced V8 as a just-in time compiler, JavaScript could now
be compiled into binary code that can be read more efficiently by a
computer, though as far as I can tell, this doesn't follow any standard and
and is likely specific to the V8 Engine

[JavaScript on Chrome]
JS Source  ------> V8-Specific Binary Code => V8 Binary Interpreter

I believe that other engines follow a similar pattern:

[JavaScript on Edge]
JS Source  ------> Chakra-Specific Binary Code => Chakra Binary Interpreter

[JavaScript on Firefox]
JS Source  ------> Spider-Monkey-Specific Binary Code => Spider Monkey
Binary Interpreter

The idea behind Web Assembly is not to act in the place of Java Source AST,
but rather in the place of the source language (JavaScript) when the source
language in the target for another language.

JS Source  ------> Engine-Specific Binary Code => Engine Binary Interpreter

WebAsembly  ------> Engine-Specific Binary Code => Engine Binary Interpreter

This is easier to understand when you consider ASM.js, (http://asmjs.org/),
a subset of JavaScript that's currently used as a compile target for other
languages.

Hopefully, it's also now clear that JavaScript isn't meant to compile to
WebAssembly -- rather WebAssembly is way of running other languages in the
browser by converting them into something that is more efficient than
JavaScript.

To revisit your original diagram,

Java Source ------> Java Source AST -------> Java ByteCode
JS Source   -------> WebAssembly    --------> ???

"JS Source" should be replaced by any generic language that compiles to
WebAssembly.
"???" will not be a standard associated with WebAssembly, but rather binary
code specific to the engine in which it's running.

Java Source ------> Java Source AST -------> Java ByteCode
{Generic Source}   -------> WebAssembly    -------->  Engine-Specific
Binary Code.

Best,
-- John

On Mon, Jan 25, 2016 at 11:38 AM, Rahman USTA <rahman.usta.88@gmail.com>
wrote:

> Thank you all so much, it is now more clear for me. WebAssembly has a
> brilliant future 👍
>
> *Btw*: I'm Voxxed Days Istanbul <http://istanbul.voxxeddays.com/>
> conference organizer. As Voxxed team We would be happy to see WebAssembly
> talk at our event. If anyone interested to talk at our conference, we will
> be happy :)
>
> Many thanks.
>
> 2016-01-25 21:06 GMT+02:00 Derek Schuff <dschuff@google.com>:
>
>>
>>
>> On Mon, Jan 25, 2016 at 10:42 AM Rahman USTA <rahman.usta.88@gmail.com>
>> wrote:
>>
>>> Hi Jean;
>>>
>>> I'm a Java developer and I try to relate WebAssembly from my viewpoint :)
>>>
>>> For example;
>>>
>>> Java Source ------> Java Source AST -------> Java ByteCode
>>> JS Source   -------> WebAssembly    --------> ???
>>>
>>>
>> It's more like:
>> JS Source ---> (nothing, it still goes directly into the browser as
>> source)
>> C Source (or other languages in the future) -----> WebAssembly binary
>> format (call it a bytecode if you want) ---> (goes into the browser as
>> binary data)
>>
>>
>>
>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>
>