4 ms·

I would like some of what the author is smoking. In addition, I would like to see them explain exactly why they think that a full language with flexible syntax

I would like some of what the author is smoking. In addition, I would like to see them explain exactly why they think that a full language with flexible syntax qualifies as bytecode. There are so many useless assertions and falsities in this post that I'm not sure where to start, and I'm not sure that a piece-by-piece refutation is worthwhile.

wslh 13y ago
I think sooner or later a more agnostic VM in the browser will came. HTML was for hypertext, now (almost) it is for general UIs. The problem is how to make a standard if organizations like Mozilla are not part of that? I think it is not so difficult: don't have a VM? emulate it with asm.js. Do you have a VM? run your application at full speed in more advanced browsers. When Google Chrome came with a faster Javascript engine, others needed to catch up.
- jabr 13y ago
  The problem with this idea is that a new, "better" VM doesn't offer any substantial benefits over using Javascript-as-a-VM. The limitations of JSaaVM can be can addressed more easily by simply improving on the existing infrastructure. There's not a good reason to throw out what we have when incremental improvement gets us to pretty much the same point more quickly and with less pain.
  - wslh 13y ago
    Native client is faster than current solutions.
mwcampbell 13y ago
I think the word "bytecode" brings more confusion than clarity at this point. What we need is not necessarily a super-optimized, human-unreadable binary format for distributing programs. We just need a format that's standard and portable, and with underlying semantics that are amenable to a fast enough implementation. JavaScript is such a format; the fact that it's a programming language with C-ish syntax, rather than a binary bytecode format, is irrelevant at worst.
ahomescu1 13y ago
I'm not sure that a piece-by-piece refutation is worthwhile. -- it would be worthwhile because otherwise your comment doesn't really say anything useful.

wslh 13y ago

I think sooner or later a more agnostic VM in the browser will came. HTML was for hypertext, now (almost) it is for general UIs. The problem is how to make a standard if organizations like Mozilla are not part of that? I think it is not so difficult: don't have a VM? emulate it with asm.js. Do you have a VM? run your application at full speed in more advanced browsers. When Google Chrome came with a faster Javascript engine, others needed to catch up.

jabr 13y ago
The problem with this idea is that a new, "better" VM doesn't offer any substantial benefits over using Javascript-as-a-VM. The limitations of JSaaVM can be can addressed more easily by simply improving on the existing infrastructure. There's not a good reason to throw out what we have when incremental improvement gets us to pretty much the same point more quickly and with less pain.
- wslh 13y ago
  Native client is faster than current solutions.

mwcampbell 13y ago

I think the word "bytecode" brings more confusion than clarity at this point. What we need is not necessarily a super-optimized, human-unreadable binary format for distributing programs. We just need a format that's standard and portable, and with underlying semantics that are amenable to a fast enough implementation. JavaScript is such a format; the fact that it's a programming language with C-ish syntax, rather than a binary bytecode format, is irrelevant at worst.

ahomescu1 13y ago

I'm not sure that a piece-by-piece refutation is worthwhile. -- it would be worthwhile because otherwise your comment doesn't really say anything useful.