Bytecode

Florian Bösch pyalot at gmail.com
Mon May 19 06:32:17 PDT 2014


On Fri, May 16, 2014 at 10:18 PM, C. Scott Ananian <ecmascript at cscott.net>wrote:

> On Fri, May 16, 2014 at 12:49 PM, Mameri, Fred (HBO) <Fred.Mameri at hbo.com>wrote:
>
>>  maintaining performance and debuggability would be nice. But for me,
>> the main benefit of the bytecode is having my engineering team be able to
>> adopt newer versions of the language at our convenience (instead of waiting
>> 10 years until some ancient client updates their script engine)…
>>
>
> You may want to look into the following:  coffeescript, traceur, dart,
> es6-shim (etc).
>   --scott
>

Far as I see it, the discussion isn't really about bytecode. It's about
that you can't quickly/easily tack onto JS everything that's required to
make it a good virtual machine you can target from another language. asm.js
is certainly trying, but it's also so far unsupported everywhere but
Firefox. asm.js does have this problem that it it can't express available
native types (byte, short, float, long etc.) because it's running in JS,
which only knows doubles, or ints (appending bit or). And that ain't gonna
change, because if asm.js starts to rely on functionality (such as type
annotations for asm.js) that other JS engines don't have, the asm.js code
won't run anywhere else anymore.

So the discussion really is about a Web-VM that's got all the trimmings of
being a good compile target. What intermediary format you deliver to it is
quite a secondary question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140519/4f47dc76/attachment.html>


More information about the es-discuss mailing list