Hacker News Reader

Comment by Mahn | Hacker News Reader

The sad part is that there is little effort into changing this. Javascript was clearly not designed for what is being used nowadays, but browsers vendors don't believe in introducing a new client language because apparently it's hard to get everyone to agree to a new standard client language. I wonder if the people behind W3C ever considered discussing this. Those gotchas in the article above are not really a tremedous hassle once you learn to live with them, but nonetheless while working on the client side one is still left wanting more from the language.

View on HN

Because, fundamentally, replacing any part of the web platform is hard. The last big, breaking, change was GIF -> PNG. HTML -> XHTML might happen once IE < 9 becomes irrelevant, but I doubt it.

But, in the case of JS, there's one major practical constraints: Introducing a new language must not regress performance of JS. (Why? There's an absolute ton of JS on the web. Getting 1% of the web using a new language able to be quicker doesn't matter if you regress 99% of the web.)

You may think, "Sure, that's easy. You just add a second VM, entirely disjoint from JS!". Unfortunately, it's not that easy: if you allow the languages to coexist in the same page, you then need to GC across both languages (as some objects are shared between the two runtimes, primarily those relating to the DOM), and cross-VM GC is an active research area, where nothing has been shown without at least a 10% performance hit to both GC impls.

Well, then, how about having a "generic" VM that runs JS within it? You're going to have an uphill battle to get performance equal to current JS VMs, because their bytecode (ignoring V8 for now!) encodes a lot of high-level semantics of JS, which means any new language, to have good performance, would have to share a lot of semantics with JS. This inevitably puts massive limitations on what any new language can be like, and restricts it to being "JS-esque".

So what can we do? There are two basic options: subset JS, though inevitably this doesn't sort out things like `==` v. `===`, but you can get to something where you can statically check you're using a sane subset (e.g., not using `==`, not using any undefined variables, etc.); or, write some language not overly dissimilar to JS and compile down to JS (the "not overly dissimilar" restriction is a practical necessity as you can't really afford to send large language runtimes and standard libraries over the wire). In both cases, JS is ultimately the target thus it's important to keep on fixing what can be fixed with JS (e.g., the lack of a module system, the lack of memory-efficient data structures), but both can improve the situation over unrestricted JS as it is today.

I was wondering about Native Client, and if it did catch on, if people would settle for just using JS as glue code between the DOM and your NaCl extension. It would open up the opportunity to use any language that can be embedded, but might be too much of a faff for not much gain.

  HTML -> XHTML might happen once IE < 9 becomes irrelevant, but I doubt it

I think XHTML is actually declining in popularity, offset by html5.

Could not agree more. There's tons of value in using a standard, even if that standard is getting a bit long in the tooth.

Great point. But:

> if you allow the languages to coexist in the same page

What if we didn't? Perhaps each site could decide whether to use the JS VM OR the "new" VM; it's not ideal, but this could work. You know, much like what one would (usually) do server side: choose a language, stick to it.

  there is little effort into changing this

Yes, nothing at all. https://wiki.mozilla.org/ES6_plans

That's why I didn't literally said nothing at all, and it's great that there's something going on with the language, but it would be even better if we were to start new language from scratch, rethought for today.

ECMAScript 6 is hardly more than a few bandaids layered upon the existing stack of bandages applied to the gaping wound that is JavaScript.

It does not get to the core of the problems with JavaScript. It does not make the breaking changes necessary to truly fix the situation. It gives a false sense of improvement, at best.

Exactly what are the core problems with Javascript in your mind?

My only worry is how long it'll take for ES6 to get adopted. It's one thing to write a spec and implement it into the compiler yourself...it's another thing to write a spec and wait for several key browsers to implement it.

Google has been working on Dart for quite a while : http://www.dartlang.org/

At the same time nobody else agrees on this language and currently only a branch of chromium supports the VM.

This is rather political - everyone want to have controls over the next language of the web, and nobody would want to adapt one made by others.

What even worse is that we all know it's almost impossible to create a good language without some dictatorship at the beginning.

The reasons why others aren't adopting Dart are only partly political, and not for the reasons you make out: the political side of it is that most (all?) other browser vendors would much rather only add a new language with an openly developed specification for it; the technical side is there's no way to integrate it into the browser without taking a performance hit both for Dart and JS.

Dart has an open specification: http://www.dartlang.org/docs/spec/latest/dart-language-speci...

The entire project is open, the VM, the dart2js compiler, the libraries, the package manager.

As for a performance hit when integrating with the browser, what re you talking about? Any references?

An open specification, sure. But the specification is for all practical purposes controlled by Google: it's not an open standard as a result. (On the plus side, the specification now looks like it may actually be viable to make an independent implementation, which it certainly wasn't before!)

The performance hit is that inherent of having to have multiple GCs given the multiple VMs. This is part of the reason why support for non-JS VMs didn't get into WebKit proper: <https://lists.webkit.org/pipermail/webkit-dev/2011-December/.... Various citations to research around there are listed in that email.

Dartium doesn't attempt to do cross-VM GS, so that supposed overhead isn't there.

I'm not sure any such overhead would always occur, or would only happen if both VMs were in use and there were cross-heap references. It'd doesn't seem likely that cross-heap GC would have such an impact with only one heap.

Reply on news.ycombinator.com