Re: Changing the name and focus of this group from WebAssembly and binary code to WebCore etc and source code.

I agree with Alon. I have experience working on a JavaScript engine on top of
..NET VM and I can assure you that .NET is not an ideal target for JavaScript
to compile to.

> On Nov 29 2015, at 2:16 pm, Alon Zakai <azakai@mozilla.com> wrote:  

>

> I also like .NET in many ways. However, there isn't a solution for
JavaScript on .NET that can get close to the performance of modern JavaScript
engines. To not regress the web, a browser would then need to have both
JavaScript and .NET VMs, which brings a host of other issues. WebAssembly is
designed to avoid those things.  
  

>

> \- Alon  
  

>

>  

>

> On Thu, Nov 26, 2015 at 11:41 PM, Jeff Lewis
<[jlewis@vargr.com](mailto:jlewis@vargr.com)> wrote:  

>

>> " The difference seems to just be what intent people want:  
  
\- a binary virtual machine code, with a design and language that parallels
compilation to native machine code, and might invoke the parallels of
'disassembly' and 'reverse engineering' which might disadvantage web user
rights but advance some agendas.  
  
\- versus a clear source code story for the web, which is my strong
preference."  
  
Why are these mutually independent concepts? The idea, as I understood it, was
to create the foundations for a bytecode pseudomachine based system that in
the end would deliver a Java or .Net like foundation for a future web that got
us out of the 'script' mindset and into more modern and sophisticated
development (like - isolated libraries that couldn't stomp on each other).  
  
If you take a look at how .Net's CLR works - it really accomplishes both of
these goals admirably. You can compile dynamically - which gives you the
immediacy of a scripted language - in fact, you can compile IN your code for
truly dynamic real time coding, and yet you can reverse compile IL (the
bytecode .Net uses) back into source at any time. If you include the symbols,
you can debug and even reconstruct variable names.  
  
It's relatively language agnostic. There are .Net versions of Python, Perl,
PHP and so on as well as more 'classic' languages like C# and C++ - and they
all interop with each other fairly cleanly. Even better still, Microsoft has
made the core of .Net an ECMA standard and open sourced.  
  
Why reinvent the wheel?  
  
The idea of continuing forward with a web infrastructure that still squirts
tons of source code directly to a browser to be interpreted AS code seems
pointless. It's really just patching the problems with the existing system -
sort of. Because as we're seeing with this project - you'll end up still
having to support JavaScript pretty much forever anyway, so you won't really
ever be able to get much past that. With a ..Net-like solution - JavaScript
just becomes one of the supported languages.  
  
I don't actually care if it's .Net - any similar technology like Java's
Bytecode - or even a wholly new such implementation would be a huge
improvement... it's just that .Net is there for the taking and now is
completely crossplatform (or can be made so relatively easily) and is
opensource.  
  
Regards,  
Jeff Lewis  

>>

>>  
  
\-----Original Message-----  
From: JS Stats [mailto:[info@jsstats.com](mailto:info@jsstats.com)]  
Sent: November 26, 2015 7:48 PM  
To: [public-webassembly@w3.org](mailto:public-webassembly@w3.org)  
Subject: Re: Changing the name and focus of this group from WebAssembly and
binary code to WebCore etc and source code.  
  
  
The name WebCore seems well taken. Another suggestion: WebBitScript. A quick
US trademark search found nothing for bit-script, nor web-bit-script, but web-
script was popular.  
  
Expanding on the source compression efficiency, I believe it could be
competitive with whatever wasm could achieve. The key would be to have a
canonical text source style that compresses most efficiently, and any
deviation might increase compressed size to remain lossless. If the producer
wanted maximum compression they would firstly canonicalize the style of their
source text, and this could just be a compression option to ignore non-
canonical styling and text.  
  
There could be a canonical white space source convention. The canonical text
style need not be stripped of white space, rather it could use standard
indentation etc.  
  
The same principle might be used for some other source elements such as labels
that might have a canonical minified format while the compression could still
degrading gracefully if some labels were not in canonical form. For example
the producer might choose to not canonicalize function names but to
canonicalize block labels and local variables. For example the producer might
choose to keep some common local variable names, such as a stack pointer etc,
which might compress very well given their repetition.  
  
The canonical form might include specific support for comments, so that the
consumer knowns the difference between comments and non-canonical styling.  
  
Multiple text source formats (JS-like, minified JS-like, s-exp, etc) might be
supported, and if in canonical style then they could be converted to another
canonical format without loss. Source with non-canonical text would obviously
not convert without loss but could still convert to a canonical style.  
  
Anyway, it seems quite possible to focus on a primitive 'source' code without
compromising the goals of being a 'portable, size- and load-time-efficient
format suitable for compilation to the web'.  
  
The difference seems to just be what intent people want:  
  
\- a binary virtual machine code, with a design and language that parallels
compilation to native machine code, and might invoke the parallels of
'disassembly' and 'reverse engineering' which might disadvantage web user
rights but advance some agendas.  
  
\- versus a clear source code story for the web, which is my strong
preference.  
  
Regards  
Douglas Crosher  
  
On 11/26/2015 06:25 PM, JS Stats wrote:  
> I would like to make the case to the members to consider changing the  
> focus of this group from the development of a binary code to a source  
> code with a binary encoding. The difference might not sound  
> significant at first but it might make a significant difference to the  
> intent of code deployed to the web in binary format.  
>  
> In the current case source code is 'compiled' or 'assembled' into the  
> binary format and deployed in binary format. With this focus the  
> developers might be tempted to abandon any claim to the binary  
> encoding being related to the source, and for example move to a linear  
> virtual machine code without expressions or structured flow control etc.  
>  
> While it might be possible to 'view-source' the deployed code it might  
> be consider 'disassembly' or 'reverse engineering' which are very  
> loaded terms for IP.  
>  
> I believe that although the operators being developed are primitive  
> and close to the hardware, that these can still be used in a  
> structured source code with expressions and local variables etc to  
> make the code more readable and easier to write. A binary encoding  
> would still be developed that would be a one-to-one reversible  
> encoding of the source (basically a lossless compression of the  
> source). I believe this could still be a good target for the use case  
> of a compilation target which seems to be the current focus.  
>  
> I have been working away at trying to use type derivation to help  
> eliminate bounds checking, and there has been another recent proposal  
> by sunfish to use some loop analysis to help eliminate bounds checks  
> too, and while I don't have anything concrete I suspect this will be  
> much easier to define in structured code. For example, a common case  
> is to define a local constant variable with a typed that can be  
> derived such as masking a value or asserting its bounds.  
>  
> The new name would remove 'Assembly' and make it clear this is a  
> source code although primitive. For example WebCore if it is not  
> taken. The Specification language would change it's emphasis to being  
> a source code, while still supporting the use case of being a compilation
target.  
>  
> Would there be any support for such a re-focusing of the group, or are  
> the majority of people wanting a web machine code binary format to  
> compile to?  
>  
> Regards  
> Douglas Crosher  
>  
>  
  
  
  
  

>

>