3 ms·

I'm with you there, to an extent. My bet is on some sort of bytecode standard as the next step in client-side browser code. Language designers could iterate mor

I'm with you there, to an extent. My bet is on some sort of bytecode standard as the next step in client-side browser code. Language designers could iterate more rapidly with a common compilation target at a level lower than JavaScript. All the major browser JS implementations are moving towards the same type of VM. It's just a matter of time before one of the browsers adds support for running bytecode from a <script> tag. The web moves forward by progressive enhancement, not by grand sweeping redesigns. So I think "JS-next" will be motivated not by committees and specifications but by incremental attempts to expose technology that's already in place (modern browsers' fast JS VMs).

jules 16y ago
Yes, yes! Standardizing the VM is better than standardizing the language. But please don't standardize a Javascript VM that run JS fast but runs, e.g. OCaml relatively slowly (compared to a native code compiler). For things where performance is important, having fast languages run really fast is more valuable than having a slow language run somewhat fast. Using something like LLVM IR would be great, and that's what Google is doing with native client.
olavk 16y ago
The question is how that bytecode should look to provide benefit. If it's just a bytecode equivalent to JavaScript, it won't provide much benefit except parsing speed - and I don't think this is a big issue anyway. A typical stack-based VM will not provide continuations for example.
wmf 16y ago
We had a pretty good discussion about browser bytecode a month ago: http://news.ycombinator.com/item?id=1893686 http://news.ycombinator.com/item?id=1893686
stcredzero 16y ago
So I think "JS-next" will be motivated not by committees and specifications but by incremental attempts to expose technology that's already in place (modern browsers' fast JS VMs) If we had some sort of standardized support for "original source pointers" then we could have any number of languages in the browser as first-class citizens. They would just use minified JS as their compiler target. Development and debugging could be entirely in the new languages. This would be a relatively small change, but it would open up innumerable opportunities.
- barake 16y ago
  Something like the #line directive [1] from C# would be useful, though it would only work in pre-compressed JS. The real challenge would be adding support in the various 'developer tools'/consoles. 1: http://msdn.microsoft.com/en-us/library/34dk387t(VS.71).aspx http://msdn.microsoft.com/en-us/library/34dk387t(VS.71).aspx

jules 16y ago

Yes, yes! Standardizing the VM is better than standardizing the language. But please don't standardize a Javascript VM that run JS fast but runs, e.g. OCaml relatively slowly (compared to a native code compiler). For things where performance is important, having fast languages run really fast is more valuable than having a slow language run somewhat fast. Using something like LLVM IR would be great, and that's what Google is doing with native client.

olavk 16y ago

The question is how that bytecode should look to provide benefit. If it's just a bytecode equivalent to JavaScript, it won't provide much benefit except parsing speed - and I don't think this is a big issue anyway. A typical stack-based VM will not provide continuations for example.

wmf 16y ago

We had a pretty good discussion about browser bytecode a month ago: http://news.ycombinator.com/item?id=1893686 http://news.ycombinator.com/item?id=1893686

stcredzero 16y ago

So I think "JS-next" will be motivated not by committees and specifications but by incremental attempts to expose technology that's already in place (modern browsers' fast JS VMs) If we had some sort of standardized support for "original source pointers" then we could have any number of languages in the browser as first-class citizens. They would just use minified JS as their compiler target. Development and debugging could be entirely in the new languages. This would be a relatively small change, but it would open up innumerable opportunities.

barake 16y ago
Something like the #line directive [1] from C# would be useful, though it would only work in pre-compressed JS. The real challenge would be adding support in the various 'developer tools'/consoles. 1: http://msdn.microsoft.com/en-us/library/34dk387t(VS.71).aspx http://msdn.microsoft.com/en-us/library/34dk387t(VS.71).aspx