Hacker News Reader

Comment by olavk | Hacker News Reader

I'm not sure I believe in a new "built from scratch" standard language for the web. Sure, we could get rid of all the JavaScript cruft and mistakes, but wont we just replace them with fresh cruft and mistakes in the new language?

I believe in evolving the core JavaScript to be more flexible, and then innovate at a level above JavaScript, like CoffeeScript (or my own http://mascaraengine.com).

ECMA should not so much focus on building more powerful abstractions (like classes, packages) into the core language, but rather on making the core more flexible. E.g. adding continuations (if possible) would be much more valuable than adding classes, because classes can already be emulated at a higher level.

Stronger support in browsers for debugging would help everyone.

View on HN

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).

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.

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.

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

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.

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

You're right: the temptation to build from scratch is strong, and probably inappropriate. I think we're dealing with two fundamental problems:

1. Most developers don't grok JavaScript. The object model (prototype-based) really throws off a lot of folks, and the fact that JavaScript can't seem to make up its mind if it's classical or prototypical doesn't help. There are numerous other problems as well made evident, and worse, by the lousy code you see floating around.

2. Fixing and improving JavaScript moves at a glacial pace due to the rate of turnover in browser versions. Chrome has it right insofar that they make upgrades automatic, easy and transparent. As always IE is a major problem, and MS' refusal to adopt a Chrome-style upgrade process isn't helping any.

Reply on news.ycombinator.com