Hacker News Reader

Comment by MostAwesomeDude | Hacker News Reader

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.

View on HN

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.

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.

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.

Native client is faster than current solutions.

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.

Reply on news.ycombinator.com