joeedh at gmail.com
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
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
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 gmail.com> 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
> This talk also contains bit and pieces of knowledge helping to understand
> this trend.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss