joe joeedh at
Wed May 21 05:34:01 PDT 2014

After writing an ES6->ES5 compiler, I've come to the conclusion that ES5
*is* an intermediary language.  For dynamic, duck-typed languages it's not
so bad.

I always found the Dart people's arguments the most persuasive:

Basically, any language bytecode will inevitably end up targeted at the
language it was written for.  From that point of view, a web-standard
bytecode VM simply isn't feasible.

Myself, I think the only bytecode suitable for the web is raw machine code.
 One you start abstracting away from the machine level, you inevitably end
up designing your bytecode for your specific language use case.

Of course, that would be tantamount to standardizing one CPU architecture
for web applications, which is a terrible idea.  Much better to stick with
highly optimized scripting languages like Javascript and have everyone else
stick to browser plugin SDKs and NativeClient.

There is a flaw in the Dart community's arguments.  It is faster to compile
to to and execute on a bytecode VM, even if it's a purely internal one.  Or
at least, it's faster to use jump tables for  your virtual machine state
code instead of function pointers.  That's why simply executing the AST
tree (which is, after all, much easier to code than coming up with an
instruction set) is so rarely done (which is how Dart does it).

On Mon, May 19, 2014 at 2:13 PM, David Bruant <bruant.d at> wrote:

>  Le 14/05/2014 19:13, Axel Rauschmayer a écrit :
> What is the best “bytecode isn’t everything” article that exists? The “the
> web needs bytecode” meme comes up incredibly often, I’d like to have
> something good to point to, as an answer.
>  This one looks good:
> I want to suggest
> I know it's not a direct answer to your question and I know the talk is
> not 100% serious, but it builds on a trend about JavaScript that suggests
> that JavaScript can be good enough as it is and a bytecode isn't needed.
> This talk also contains bit and pieces of knowledge helping to understand
> this trend.
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list